Introduction

My home desktop has been running Ubuntu 18 since it came out in April 2018. As all even numbered versions, it has LTS (long term support) for 5 years, which ended last year. Yet the reliability of Ubuntu is a double edged sword. It runs so long, without filling the hard drive with garbage, without fragmenting the filesystem, without losing performance, that over the years you customize it so many ways that by the time you need to upgrade, it’s hard to remember everything you’ll need to set up in a new system.

So why upgrade at all? After 5 years there are no more updates. No more security patches, and for most of the applications you can only run old versions. So you need to upgrade to use the latest versions of applications and stay on top of security.

You can upgrade in place to keep everything you’ve configured, with do-release-upgrade. But this only takes you up 1 step to the next LTS version (18 to 20, 20 to 22, etc.). So I’d have to do that 3 times! And it doesn’t guarantee that everything you set up will work – though it usually does.

This time around, 6 years and 3 versions behind, I decided to do a full upgrade from 18 to 24 and wipe the system boot drive. I waited until Ubuntu 24 was released on April 25 and then hit the keyboard.

Install

I actually use XUbuntu, a variant of Ubuntu that uses the XFCE desktop instead of Unity. I prefer the XFCE desktop, as it is more traditional and faster, using less CPU and RAM. Even if the computer is fast enough to support a more heavyweight desktop, why waste the CPU and RAM on that? Even if Unity was as lightweight and fast as XFCE, I would still prefer XFCE.

First I backed up my system using deja-dup. Most of my data files are on separate hard drives, which I would not be erasing. So I only needed to back up my home directory and an “apps” directory that I use for software that is manually installed. I also reviewed my apps and files to ensure that all the software I wanted to install was available on my data drive: DEB, TAR, etc. As my desktop has 4 drives, I wrote down the device and UUID for each so I could recognize them during installation.

Next I downloaded the ISO file, burned it to a DVD, rebooted to the DVD which started XUbuntu. I selected to do a manual install, reformatting the system drive. I selected “minimal installation” because I didn’t want a bazillion crapplets that I’ll never use, but also “include 3rd party and binary software”. This all went smoothly and it also automatically installed the NVidia drivers for my GTX1660.

Next, I removed the DVD and booted, my computer came up in XUbuntu 24. Yay! But now the real work begins…

Configuration

Firefox

Firefox is a mess in Ubuntu 24. First, by default it installs as a Snap, which nobody likes. And, on top of this, they’ve crippled its access to the filesystem. You can remove it from Snap with snap remove firefox and then install with apt install firefox, but the next time you update it will revert back to the Snap install. To get it to stay this way you’ve got to edit some config files to tell the system to always install it from apt.

Next, I found that Firefox could not download files. After scratching my head for a while I realized this is because my home Downloads folder is a link that points to my data disk. And I also discovered that I could not open local documentation HTML files for the Android and Java SDK. Putting 2 and 2 together, I realized that someone decided to cripple Firefox’s access to the filesystem. WTF!?

I suspect this is the “younger generation” of developers, who think the local filesystem is somehow “unsafe”, and really unnecessary anyway since they do everything in the cloud. That is the only reason I can imagine for the crazy idea of crippling such an essential function. Most sites say that installing Firefox from apt instead of Snap solves this. Perhaps it once did, but not anymore in Ubuntu 24. With some Googling I learned they’ve created an AppArmor config that restricts filesystem access for Firefox. My fix was to configure AppArmor to disable the Firefox controls, like this:

sudo ln -s /etc/apparmor.d/usr.bin.firefox /etc/apparmor.d/disable

Altogether, this got Firefox working properly again.

Backups: Deja-Dup and Duplicity

To restore all of my backups I’d have to be root because some of the files to be restored are system, owned by root not by me. No problem, right? Think again. My backups are on a separate disk that I mount to a local folder /dsk3. When I ran deja-dup to restore a backup, it would unmount that drive!

If I ran deja-dup as myself, it would work only because it wasn’t root so its attempt to unmount the drive would fail. This was fine, it still worked, even if only by accident. But with deja-dup it is impossible to restore a backup that you have mounted to a separate disk, if you run it as root.

I could not find a solution to this, so I only restored my home and apps directories mentioned above. That’s all I really needed to back up, so I got lucky.

Thunderbird

I installed from apt and it saw all of my email that was restored from the backup – both my local folders and all of my IMAP email server accounts. Bang!

Python and Virtualenv

In Ubuntu 24 Python works differently. The system Python is now 3.12 instead of 2.7, which is nice. But the procedure for installing virtualenv and virtualenvwrapper that I used for Ubuntu 22, does not work in 24.

First, use pipx instead of pip. That is, pipx install virtualenv.  After that, pipx install virtualenvwrapper. At this point they are installed but the don’t work. Next, I had to change the environment variables and python & wrapper script locations:

export WORKON_HOME=$HOME/.virtualenvs
export VIRTUALENVBIN=$HOME/.local/share/pipx/venvs/virtualenvwrapper/bin
export VIRTUALENVWRAPPER_PYTHON=$VIRTUALENVBIN/python
source $VIRTUALENVBIN/virtualenvwrapper.sh

I created some virtualenvs, listed them, etc. it all works fine – great!

Pulseaudio and Pipewire

Ubuntu 24 audio is working, but it runs pipewire instead of pulseaudio. I had pulseaudio configured to avoid resampling for bit perfect audio. Pipewire is not doing this; it resamples everything to the system default sample rate of 48 kHz. With some reading, I found a simple way to configure this.

The pipewire config files reside here: /usr/share/pipewire

In particular, the primary config file is: /usr/share/pipewire/pipewire.conf

But rather than edit this directly, you can leave it in place there and create another config file that overrides individual settings.

Create this directory if it doesn’t already exist: /etc/pipewire/pipewire.conf.d

And in that directory, create text files (having any name) that override individual settings. For example I created this file: /etc/pipewire/pipewire.conf.d/pipewire-custom.conf

# Daemon config file for PipeWire version "1.0.5" #
#
# Copy and edit this file in /etc/pipewire for system-wide changes
# or in ~/.config/pipewire for local changes.
#
# It is also possible to place a file with an updated section in
# /etc/pipewire/pipewire.conf.d/ for system-wide changes or in
# ~/.config/pipewire/pipewire.conf.d/ for local changes.
#

context.properties = {
    ## Properties for the DSP configuration.
    default.clock.rate = 48000
    default.clock.allowed-rates = [ 44100 48000 88200 96000 176400 192000 ]
}

stream.properties = {
    resample.quality = 14
}

After doing this, when I play audio files using VLC, with an external DAC connected to my sound card’s SPDIF output, the external DAC shows the sample rate changing to the native sample rate of each file that I play. It works!

Also: the DSP library PulseEffects was replaced with EasyEffects, a newer version that works with PipeWire. This new version has a feature I like: it does not resample all audio to the system sample rate like PulseEffects did, but plays audio at its native rate without resampling, changing the system rate to match the audio. Very nice!

Audio Update

Audio stopped working on each bootup. After some troubleshooting I discovered that the kernel module for my Juli@ sound card is not loaded. How to check this?

First, run lspci -k and it shows you all your PCI cards, and for each, which kernel module it uses. This told me the card is plugged in and the module is snd_ice1724.

Next, check whether that module is loaded, or really check for all sound modules by running: lsmod | grep snd_. This did not list the snd_ice1724 module.

So, load the module manually by typing: sudo modprobe snd_ice1724. After that, repeat the above command to see if it’s loaded. Bingo! It was. And after doing this, audio started working.

Now here’s the mystery: normally you can tell the system to load new kernel modules by creating files in files in /etc/modules.load.d. For example I created this file:

-rw-r--r-- 1 root root 53 Apr 29 18:02 /etc/modules-load.d/snd_julia.conf

The contents are simple:

# kernel module for the Juli@ sound card
snd_ice1724

This should tell Linux to load the module at boot, so I don’t have to load it manually. But my system still doesn’t load this module. Or maybe it’s trying but failing, but I can’t find any errors. And I also looked for it in blacklists, but it is not a blacklisted module. Indeed, if it were the system shouldn’t let me load it manually.

At least I can fix the problem, but I don’t know why it doesn’t load automatically when it detects the sound card, nor manually from the config file, so I’m stuck loading this module manually at the command-line.

PS: another kernel driver that I must load manually is snd-usb-audio. This is needed to use external DACs that plug in via USB, like my Schiit Jotunheim. Add it to the list above.

Java, Tomcat and PostgreSQL

I installed openJDK versions 8, 11 and 21, using apt, then ran update-alternatives to set the default to JDK 8. Even though it’s old, a lot of software requires it and won’t run on the newer JDKs.

Next I installed Tomcat, version 10 is what comes with Ubuntu 24. That was simple enough.

Then I needed the PostgreSQL JDBC driver so my Tomcat server could talk to databases on other servers in my home network. I found the JAR file online, copied it to /usr/share/java and linked it to /usr/share/tomcat10/lib.

Finally, I copied my audio recordings JSP app to Tomcat. First I made a directory for the app: /var/lib/tomcat10/webapps/audiorec. Then I copied the source files (JSP) to that directory. BANG! It just worked.

Apps and Games

I installed Steam and after configuring it, it saw all of my games on my separate disk drive. And it saw my configs since I restored my home directory. All good? Nope.

Two games I’ve been playing recently are Valheim and Bioshock Infinite. Steam showed how long I had been playing and when I most recently played. And the games are supposed to save your progress in the cloud. But when I started the games, they started from scratch. They had no notion of any prior game play or saves. I lost all my progress in the games.

On the brighter side, the games now run natively in Linux, where previously with Ubuntu 18 they only ran reliably from Proton, the Windows emulator. Same hardware, same drivers, the only difference is Ubuntu 24 versus 18. So I don’t know why, but that is nice…

Printers and Virtualbox

Back in 2019 I bought the TurboPrint driver for my Epson SureColor P400 printer. This is a good thing, since Epson doesn’t have a Linux driver for this printer – even though they do for most of their other models. Yet the TurboPrint driver installed and worked just fine, it doesn’t need the Epson driver. Turboprint is excellent, and essential for anyone who wants to print photo quality from Linux.

I have a Windows 10 VM for software that doesn’t run on Linux. Just a couple of apps, Epson’s CD print and Suunto’s link for my GPS wristwatch. I installed virtualbox simply from apt and it just worked – my VM came up just fine. Of course I did have to edit my system groups to ensure that I am in both plugdev and vboxusers in order for the Windows VM to be able to see USB devices like the printer and the watch.

Addendum: IOMMU

What the heck is IOMMU, you might ask? Indeed, I asked the same. I noticed a bunch of errors in dmesg, like this:

DMAR: DRHD: handling fault status reg 3


With some Googling I found it is related to a CPU chip function related to RAM called IOMMU. I’ve been using Linux since Ubuntu 8 in 2009 on a wide variety of desktops and laptops, and I’ve never seen this before. Maybe this desktop’s CPU is too old to support it – it’s an i7-4770 from around 10 years ago. Still reliable & fast, so why replace it?

The solution was to add a kernel boot parameter iommu=soft. I did this by editing the /etc/default/grub file, then running update-grub. Confirmed fixed.

Conclusion

Of course there was a bunch of other stuff. And I’m not even done yet. But the computer is mostly working again, with most of my data and apps restored. I’ll get the rest of it working over time.

The Tascam DA-3000 is a professional rack mount digital recorder. For years I owned a prior model, the SS-R1. It provided years of reliable service and I used it to archive nearly 1,000 vinyl LPs. The DA-3000 improves upon the SS-R1 in a few important ways:

• Better AD converters: Burr Brown PCM4202
• Better DA converters: Burr Brown PCM1795
• Uses dual AD/DA converters, one per channel, each in mono mode
• Supports higher data rates: 24 bit, up to 192 kHz PCM and DSD 128 (5.6 MHz)
• Direct AD-DA mode
• Lower distortion and noise

It also retains many of the most important features of the SS-R1

• Records to SD and CF media (no internal hard drive)
• No fans – dead silent
• The flexibility of many connections
  • Analog unbalanced RCA input and output
  • Analog balanced XLR input and output
  • SPDIF coax input and output
  • AES/EBU input and output
  • Internal or external clocks
• Professional build quality, durability and reliability

Tascam no longer makes the DA-3000 so I bought mine used from eBay. In using it I’ve discovered some interesting quirks.

Date/Time Clock

The SS-R1 had a clock that had to be set every time you powered it on. Even when plugged in, it would forget the date & time when turned off. The DA-3000 fixed this – at least supposedly. But every time I powered mine up, I had to set the clock.

The problem was that the DA-3000 uses a rechargeable button cell battery to remember the clock when turned off. And it uses a tiny one that is soldered to the board. After a year or two, this battery dies and is not easy to replace (you must disassemble the unit, remove the board and solder). I contacted Tascam support and they said they no longer provide this service. It was annoying enough I decided to do my own permanent fix, better than what they would do at the factory.

Rather than simply replace that soldered-in battery, I installed a small battery cage for a CR2032 battery, which has the same voltage but is more than twice the size and capacity. Instead of soldering a new battery onto the board, I soldered the battery cage lead wires. Here’s what it looks like now:

I put an ML2032 battery into the cage (the rechargeable version of a CR2032). Not only will it last much longer than the tiny OEM battery, when it dies I can now replace it in 10 minutes easily without any soldering. This is how the DA-3000 should have been built from the factory.

DA-AD Mode

This mode stands for “Digital-Analog, Analog-Digital”. In this mode, the DA-3000 doesn’t record, but merely activates its DA and AD converters. You select which analog & digital inputs & outputs it uses. The DA converter has a slightly warm, soft voicing free of glare yet not veiled. Very nice. Most DACs sound the same to me all having a touch of glare, but the DA3000 is just slightly different. I can find no explanation for this in measurements, as its frequency response and distortion measure clean.

DA-AD mode does not auto-detect the sample rate. You must select the sample rate in the menus. If the sample rate you select does not match the digital input, the DA-3000 will still produce analog output but it is distorted. By this I mean high frequencies rolled off with elevated harmonic distortion.

Frequency response in DA-AD mode with sample rate mismatch, compared to sample rate match.

Distortion in DA-AD mode with sample rate mismatch:

For comparison, here’s distortion when you manually set the rate to match the input:

This distortion is measured after the DA3000 DA conversion and the SSR1 AD conversions. The distortion when you don’t manually set the sample rate to match the input is not documented in the manual, and Tascam support did not respond to my inquiry about this. So just know about this and set it!

Sample Rate Sensitivity

The popular S/PDIF digital format (whether coax or toslink) is a “push” protocol. The source device sends data to the downstream target using the source’s clock. The target device has no way to tell the source to slow down or speed up. No two clocks ever agree exactly, so the target device has to adapt to the source device sample rate. In contrast, audio over USB is a “pull” protocol. The downstream target device runs off its own clock, requesting data from the source as needed. No need to synchronize clocks or adapt sample rates.

Lest anyone disregard S/PDIF clock sync as a problem “solved in the real world”, consider that well engineered DACs use TCXO for their clock, which are temperature compensated crystal oscillators. These are typically accurate to roughly 1 ppm, which at CD quality 44.1 kHz makes a clock drift of 1 sample every 22.6 seconds. So the issue is real – with S/PDIF, the downstream device must adapt to the upstream clock. Buffering can’t entirely solve this, because it can only solve variations around an identical center frequency. Put differently, no two devices will ever agree on the center frequency, one will always be slightly slower than the other, which means any buffer you use will eventually under/over flow. With S/PDIF the downstream device must not only buffer the data, but also adapt its clock to the source rate.

The Tascam DA-3000 specs say it can sync to any input digital sample rate within a range +/- 100 ppm. This should be plenty, about 100x greater than the drift expected from a well engineered DAC. However, in my setup I have a toslink-coax converter between my Corda Soul (preamp/DAC) and the DA-3000. This converter causes quite a bit of jitter, so much that the DA-3000 occasionally loses sync. For example, a REW frequency sweep played through the Soul and captured on the DA-3000 looks like this:

That capture was at 88.2 kHz sampling, but it happens at all sample rates. My Topping E70 DAC handles this jitter just fine and is super clean, because it has a setting called DPLL that controls how much sample rate variance it can accept and adapt to. I had to bump it up a couple of notches to handle the switchbox.

Fortunately, the DA-3000 can do the same thing, even though one method for doing it is undocumented. When recording, enable SRC which is Sample Rate Conversion. This won’t actually convert the sample rate, because you’ll still manually set the DA-3000 sample rate to match the digital input. But when SRC is enabled, the DA-3000 accommodates and adapts to a wider range of jitter.

A better, cleaner method is to change the DA3000 clock setting from “Internal” to “DIN”. This tells the DA3000 to use the digital input as its own reference clock.

When you do either of these, distortion in the REW sweep is super clean like it should be:

AD Converter HF Noise

Another quirk of the DA-3000 is super high frequency noise in its AD converter. The noise is at 100 kHz, so you won’t see it at sample rates of 96k and lower since it’s above the Nyquist frequency. But at 176.4 and 192 kHz, it is there and looks like this:

So, if you are recording from analog inputs, don’t use 176.4 or 192 kHz. Use 88.2 or 96 kHz instead. The sound quality will be better! This is not an issue if you are recording digital inputs – that is just a bit perfect copy.

Analog Output Level

Normally, a recorder’s analog output level isn’t that important. But when using the DA-3000 in AD-DA mode, it becomes so. You need to match the input voltage sensitivity of the downstream preamp. The DA-3000 has a setting called “Reference Level” that sets this. Indirectly, this sets the analog output voltage for digital peak levels. The range is -9 dB which is +15 dBu (quiet) to -20 dB which is +24 dBu (loud). In Volts RMS this ranges from 4.36 to 12.28. The first is the consumer audio standard, the second is the professional standard.

Most consumer preamps have voltage sensitivity for their balanced analog inputs that expects peak levels around 4 V. Higher voltages can cause them to clip or distort. So you would set the DA3000 to -9 dB.

The Corda Soul has an internal switch to set its analog input voltage sensitivity. The default setting is for professional audio, expecting 12 Volts (low gain). Flick the switch to the other position and it changes to consumer, expecting 4 Volts (high gain). With the Soul set to low gain, the DA3000 setting that matches the output level of the Soul’s internal DAC is -16 to -18: -16 is about 0.5 dB quieter and -18 is about 1.5 dB louder.

Conclusion

The Tascam DA-3000 is a wonderful recorder. It is incredibly flexible, easy to use, with SOTA transparent sound quality and professional build quality. It has many other features not described here, since I’ve focused on its quirks. I’ve wanted one for years and I am so happy I finally found it!

Like any piece of gear, it has a few quirks as seen above. But none of these are serious problems, they all have workarounds.