Minimizing Dropouts when recording

Audacity Help Forum GNU/Linux
1

I’m looking for other people’s experiences with reducing dropouts when recording.
My goal is to digitize some old cassette tapes (some of these are recordings made by local musicians, from before CDs were invented, and AFAIK they are irreplaceable). I have about 20 of them that belong to my GF (major karma points if successful).

I’m using Kubuntu 20.04, with Audacity 2.3.3 from their repository. Build date March 22, 2020, commit ID 008d8d Nov 15

Hardware is an HP/Compaq DC7800, Intel Core 2 Duo E6750, 2.66 Ghz, 3.8 GiB of RAM, NVIDIA GT218 (Geforce 210). I’m using this because it’s the only computer I have with a proper line-in jack. It seems like it should have sufficient horsepower. (I assume the missing .2GiB of RAM is for the onboard video buffer, even though I have a separate video card-- I don’t think it can be set any lower).

I’m using the raw devices for recording and playback, ie hw(0,0). Using anything else seems to make Audacity lock up. I haven’t tried installing JACK. I’ve found that it’s important to “rescan” for devices, because they didn’t all show up the first time I ran Audacity.

The dropouts are audible in the passthrough audio when recording, and on playback. They seem to be somewhat less audible when exported to MP3s, but they’re still there. I want to keep the passthrough audio enabled so if something goes wrong with the tape transport, I can hear it immediately (I don’t know what kind of condition these tapes are in).

Some things I’ve noticed so far:

–Using 16 bit samples instead of 32 bit helps a lot, but doesn’t completely solve it. I would say this is a mandatory starting point.

–Running the mouse pointer over certain toolbars causes dropouts, even without clicking on them
–Any window activity, anywhere on the screen, causes dropouts
–Would installing a lightweight window manager help? Has anyone done a direct comparison? KDE isn’t known for being lightweight.
–Would using a smaller monitor help? (fewer pixels to wrangle)

–Running audacity with nice -20 seems to help quite a bit
–Is there a general way to reduce the priority of anything graphics-related?

–Turning off Wifi might help, it’s hard to tell

–I’ve tried changing the “audio to buffer” setting, but I can’t tell that it makes any difference.
–Would it help to tell Audacity to store temporary files on a RAMdisk? (ie, tmpfs)
–Why isn’t there an option to buffer the whole track in RAM? One side of a cassette should be about half a CD worth of data, which isn’t that much when I have 4GB of RAM.

–Minimizing the Audacity window seems to help, although that means I can’t see what’s going on (eg, clipping). That means I have to be careful with recordings that have a lot of dynamic range. But I can deal with it.

–Un-checking the box that says “Auto-scroll if head unpinned”, and zooming out so that the track display doesn’t have to scroll, seems like it helps, but may be irrelevant if the window is minimized? (I hadn’t tried minimizing the window yet when I did this)
–Is there a way to completely suppress the track display while it’s recording? I can shrink it, but it doesn’t completely go away.

–Is there any way to get statistics on how wide the dropouts are, ie how many samples are missing each time? I assume narrower is better.

–My most recent experiment went pretty well, so I think I’m getting there. I had a solid run of over 10 min with no dropouts (in a 30 min track), and some of the others were due to me experimenting with various things while it was recording.

–Anything else I haven’t thought of yet?

2

Those symptoms suggest that the computer is substantially under-powered. Moving windows / toolbars will always require a bit of CPU, but normally just a few percent of one processor core.
Using 16-bit samples compared to 32-bit should make virtually no difference at all unless the system is struggling to write the data to disk, which shouldn’t be a problem even with a slow 4,500 rpm hdd.

I use Xubuntu on an i7 laptop with SSD. I’ve not tried KDE in a very long time, but I tried Gnome a while back and was shocked by how heavy and sluggish it was compared with Xfce.

Personally I’m a big fan of Xfce as it is a full featured Desktop environment, while still pretty light on resources.

3

I did some more experiments.

First, I remembered that I have another computer, which I thought was similar to the one I mentioned earlier, but it turned out to be a different model (in particular, it seems to have better video hardware). I did some test runs, which were inconclusive. I was getting 15-20 dropouts in a 30 minute track (not evenly spaced), no matter what I did.

But this seems like a latency issue rather than a raw horsepower issue-- something wasn’t getting buffered properly, so when several things happened at the same instant, samples were dropped. I thought this might be related to having to use the raw hardware device instead of PULSE for input, but the newer computer might not have that limitation.

I’d read that JACK was designed for low latency, but also that it was complicated and not well supported. So, I installed jackd and qjackctl, clicked some buttons, and it just worked. I made a 30 minute track with just ONE dropout. (This is still using Kubuntu).

There are some details to pay attention to, and I’m sure there are more things to learn about JACK. AFAICT, the main things seem to be:

–Launch qjackctl first. Select the right input device (in this case, line-in). Click “start”. Nothing else seems to be necessary, although there are lots of other settings available.
–Launch Audacity, after JACK is running. In the device toolbar, make sure the host is set to JACK instead of ALSA, and the input device is set to SYSTEM. JACK will not be listed if it wasn’t running when Audacity launched.
–In the transport toolbar, click Pause, then Record, then un-pause.
–Start playing the source
–click Stop when done.

So far, I’m calling that success.