Popping and crackling audio even on high latency on a "good" pc

Installation & Configuration Linux
#21

Just a pedantic point, but 512ms is half a second, which would be absolutely huge latency. I think you probably mean 512 samples per buffer, which is usually around 10.5-11.5ms per buffer, depending on sample rate.

The other parameter which is relevant is buffers per period, meaning how many buffers of audio samples are kept in process at once. I believe you said you are using the ALSA backend of Ardour, which if you have not gone out of you way to change will use 3 buffers per period (labeled as “periods” in the Audio/MIDI setup dialog). I believe 3 may be specific to USB interfaces, if you happen to have a PCIe connected interface it may default to 2. Since you mentioned using a UMC USB interface you can double check to make sure you did not change from the default of 3 for USB.

As far as I am aware, the memlock setting will not typically cause xruns, it will show up in e.g. a software sampler plugin unable to load the entire sample set, or some other memory allocation failure.
An insufficient rtprio setting would be much more likely to cause xruns, so was that addressed by getting your user added to the audio group?

The lack of threadirqs kernel command line may cause problems. You generally do not need full preempt-rt configuration to run down to 256 samples/buffer, but having either preempt-full, or dynamic preemption with the mode set to full (or lazy if you have a recent enough kernel) will provide better performance for realtime scheduled tasks like the Ardour audio processing thread.
You can check your current kernel preemption configuration with this command, which will print output similar to this (the value with parenthesis indicates the mode currently in use):

$ sudo cat /sys/kernel/debug/sched/preempt
none voluntary full (lazy)

If your configuration has the parenthesis around either “none” or “voluntary” you may be able to change that easily depending on how Mint configures the kernel.
This command will show what preemption configuration options were chosen at build time for the kernel. If the dynamic options have a “y” then you can just modify the kernel boot parameters without having to install new kernel:

$ grep PREEMPT_DYNAMIC /boot/config-`uname -r`
CONFIG_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC_CALL=y

If those values are “n” then you should check to see if Mint has a different kernel in the repository with something like low latency in the package name.

1 Like
#22

I’ve become a big fan of Ubuntu’s realtime kernel (available on Ubuntu 22/24 Pro for AMD/Intel).

The guys on the Linux Studio project swear by their low latency kernel, too.

Ardour will promote its DSP threads to realtime priority if the kernel supports it and Ardour has suitable permissions (CAP_SYS_NICE).

1 Like
#23

Hey there
Finally got some time to read through your observations.

That is correct, yes, thank you for the correction

It really was set to 2, instead of 3. Changing it back to 3 made it so I don’t hear any noise at 512 samples per buffer (which by itself is already amazing), but I can still hear it at 256. What would be your advice regarding this? I could keep recording in 512, but I seems like the geral consensus is that 256 is overall better for instrument recording so maybe it’s worth it to keep looking for possible changes, right?

Regarding the kernel preemption configuration, it is currently set to (voluntary), and the dynamic options all have a “y” as follows:

CONFIG_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC_CALL=y

#24

Having fewer samples per buffer is only needed if you’re using software plugins to create the sound.
Like if you’re plugging your guitar cable directly into the sound card and then using Guitarix or some other simulation software to actually create the sound you’re recording.

In that case you’ll notice an obvious delay between hitting the string and hearing the sound if you have higher s/b settings.
The same goes for MIDI and software synths.

If you’re recording an actual guitar amp or vocals through a microphone or a hardware synth or something similar you can go as high as you want.

Here’s a few pointers on latency and latency compensation in Ardour

1 Like
#25

As pointed out by Peter Hedlund it very much depends on what you mean by “instrument recording.”
If you mean you are playing a physical instrument of some type and recording that, then you can set the latency has high as you want as long as you have some way separate from Ardour to monitor what you are playing (either listening to the instrument directly if it is loud enough, or using something like an analog mixer for monitoring if playing an electronic instrument).

If by “instrument recording” you mean recording instruments which are only software plugins running in Ardour, or separate software programs running on the same computer and routed to Ardour, then yes, lower latency is often more comfortable because it will reduce the time between pressing a key or hitting a pad and hearing the sound play.

Then you could expect to get better performance with either full or lazy preemption (lazy is like full, but if there are no realtime tasks running makes some allowances that help throughput oriented tasks).

Consult the Mint documentation to find the method that fits best with that distribution, but the end result you want is that the kernel boot command line adds preempt=full and threadirqs to the existing kernel command line.
The way I have used in the past seems to have been superseded by an easier method. You can try this to see if Mint includes this grubby program to modify the entries in the grub bootloader configuration:

sudo grubby --update-kernel=ALL --args="preempt=full threadirqs"

You may have to experiment a bit, I think the quotation marks will be required to add two new arguments simultaneously, but I haven’t verified that syntax yet.
The next reboot after making the change should use those new arguments.
If your kernel supports lazy preemption and you want to experiment with that use “lazy” in place of “full.”
You can check whether your distribution kernel supports lazy preemption with this command, and check for the “y” in the output lines:

$ grep LAZY /boot/config-`uname -r`
CONFIG_ARCH_HAS_PREEMPT_LAZY=y
CONFIG_PREEMPT_LAZY=y

In my kernel config I no longer see an entry for CONFIG_PREEMPT_FULL, so I think LAZY may have superseded FULL in the configuration, even though the kernel scheduling debug entry still shows that full is a valid scheduling option from the kernel command line. So if you grep for all the CONFIG_PREEMPT entries in your kernel config, depending on your kernel version there may or may not be entries for LAZY or FULL.

I am using hardware monitoring myself, so I have not tried to see how low in latency I can achieve these days, but I think with recent kernels and full or lazy preemption settings with threadirqs you should have a good chance of running at 256 if you decide that is what you want.

1 Like
#26

This is very important. What I found out is ALWAYS use a back usb port gor Audio devices like my usb mic and my RP150, but Never front usb.

#27

That is very machine layout dependent, you cannot generalize that rule to all computers.
You must look at the USB device tree to determine which ports are connected to the same hub.

1 Like
#28

Has anyone tried installing the Ubuntu Studio Installer on Mint? (apt install ubuntustudio-installer) One of the things it can do is set up your machine for pro audio automatically, setting kernel, rtprio, users, performance profiles etc automatically. I don’t know if it’d work on Mint though, or hose it. I did try it on ElementaryOS once, selecting only the performance tweaks and low latency settings, and it worked fine.

#29

Hey Ian, if you can install the timeshift package, do so and run it (GUI also available). It is kinda like Time Machine on Apple and Restore on Windows. It things go wrong, you can completely restore your OS to its previous state, and fairly quickly too for that matter. Just insure you have a rescue kernel to boot from if things go badly and you can restore it easily.

With that said, if Linux Mint is based on Ubuntu, it should work. I’ve never used it so I don’t know the specifics of it, as I only have used RedHat/Fedora on servers and desktops (since ~1995) and Debian on RPis.

This installer is such a GREAT idea! While Fedora does give similar options, a RT kernel is not one of them. Well, it does indeed include a semi-RT kernel, it is not enabled by default.

Using Jack with Pipewire works very well on my system. 24/96 for everything. It works perfectly with both my Nvidia HDMI audio and my Behringer UMC202HD.

1 Like
#30

That was previously the case, but recent kernels in Fedora 42 compile with dynamic preemption, which allows changing the preemption class at boot time, and have lazy preemption as the default, which is a superset of CONFIG_PREEMPT (aka full preemption, which is still distinct from preempt-RT).
I had previously added threadirqs to my kernel command line, although I am not sure whether it is still required to be explicitly set when using CONFIG_PREEMPT or if that is implicit now. It does not hurt to still have it set on the cmdline arguments, so I am leaving it until I find any definitive documentation that threadirqs is no longer needed on the kernel cmdline.

1 Like
#31

Updates:
I think that I’ve got every task pointed by Millisecond completed.

Now, for some reason, I can still hear the clicks recording at 512 samples per buffer, so it’s back to square one unfortunately.

I will definitely try this out!
Thanks again

#32

Does your distro deploy cpu-dma-latency.rules from ardour/tools/udev at master · Ardour/ardour · GitHub ?

see also Ardour scheduling udev rule thingie? - #2 by peder

#33

Hey, Robin! Finally got some time to read through your answer again (crazy last couple of weeks got me off the computer almost entirely haha).

I think so, the file is copied to rules.d.

What I couldn’t do yet was to compensate latency through the Audio/MIDI setup window. I use ALSA and when ALSA is selected I can’t seem to press the “calibrate audio” button. Is there a way to do this without JACK/PIPEWIRE?
Thanks!