The smaller the Audio Buffer you select in Mixxx's Sound Hardware Preferences, the faster you will hear changes when you manipulate controls in Mixxx, on a controller, or with timecode vinyl. However, lowering it beyond what your system can handle will cause audible glitches (pops). Here are some tips to configure your system to handle lower latency audio:
In Preferences > Sound hardware, if there is a link to this page, Mixxx is not running with real time priority. To enable Mixxx to run with real time priority, you will need to set up your kernel and scheduling permissions.
To use real time scheduling, you will either need to boot Linux with the “threadirqs” parameter or use a kernel with the realtime patch set. To always boot with the “threadirqs” kernel argument, add it to your grub.cfg by editing /etc/default/grub as root, adding “threadirqs” to the line for GRUB_CMDLINE_LINUX, then generate a new grub.cfg file. On most distributions, do this by running grub-mkconfig -o /boot/grub/grub.cfg
. On Fedora, run grub2-mkconfig -o /boot/grub2/grub.cfg
if you boot with BIOS (legacy) or grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
if you boot with EFI (if /boot/efi does not exist, you boot with BIOS). Reboot. Check that you have booted with the “threadirqs” kernel parameter by running grep threadirqs /proc/cmdline
. If you booted with the “threadirqs” kernel parameter, all the parameters you booted with will be printed. If there is no output, you did not boot with the “threadirqs” kernel parameter.
To use a kernel with the realtime patch set, Fedora users can install the kernel-rt package from the Planet CCRMA repository. Ubuntu users can install the kernel-rt or kernel-lowlatency packages. Crossfade and Ubuntu Studio are distributions that come with a realtime patched kernel. Arch Linux users can install the linux-rt or linux-rt-lts packages. Note that kernels with the realtime patch set may have some stability issues.
Whether you are using a generic kernel or a kernel with the “real-time patch set”, your user needs permission to create threads with a real-time scheduling policy (SCHED_FIFO
or SCHED_RR
). This permission is disabled by default on major distributions due to denial-of-service risks (a user with realtime permissions can easily hard-lock a machine, requiring reboot). Distributions such as Ubuntu Studio enable this permission by default.
Set the maximum rtprio for your user by editing /etc/security/limits.conf
as root and add <your user name> - rtprio 99
to allow Mixxx (and other processes you run) to increase their thread priority to maximum. Reboot for this to take effect.
On Arch linux, install realtime-privileges, and usermod $USER -a -G realtime
to add your user to the realtime
group. Logout and log back in for the changes to take effect.
You can use cyclictest
(see below) to verify that your user has permission to schedule realtime threads.
To test your best-case latency (CPU-only) using realtime threads, cyclictest
and hackbench
from the rt-tests package are useful.
# Generate some load on the kernel scheduler. hackbench -l 10000000& # Test the latency a SCHED_FIFO thread sees when attempting to wake up once per millisecond. cyclictest -s -i 1000 -l 10000000 -m --policy fifo # Don't forget to kill hackbench when you're done: pkill -9 hackbench
Do not run the above commands via sudo! If you cannot run these as an unprivileged user, then your /etc/security/limits.conf
change did not work.
The output will look like this:
T: 0 ( 8078) P: 2 I:1000 C: 3601 Min: 9 Act: 13 Avg: 11 Max: 254
The number to watch is the “Max”, which tells you the maximum observed latency in microseconds between the desired wake-up time and the actual wake-up time. For a SCHED_FIFO
thread on a realtime kernel, a max latency of under 10 microseconds is easily achievable. For a generic kernel, this will be harder.
To see how a non-realtime thread behaves, try –policy other
, which uses the SCHED_OTHER
scheduling policy (the default).
IRQs (interrupt requests) allow devices to get the operating system kernel's attention. You can improve the audio performance of your computer by configuring your OS to give more attention to your sound card than other devices. This will not have any effect unless you have enabled threadirqs with a generic kernel, or are running a kernel with the realtime patchset.
The easiest way to raise the IRQ priority of your sound card is by installing rtirq and setting it to run on boot. To set rtirq to run on boot on distributions using systemd (which is most distros), run systemctl enable rtirq
. Check that rtirq set your IRQ priorities correctly by running rtirq status
. The IRQ for your sound card will end in ehci_hcd for devices plugged into USB 2.0 ports and xhci_hcd for USB 3.0 ports. If it is not a USB sound card, look for “snd” in the last column. This should be above other IRQs listed by rtirq status
. The configuration file for rtirq is located at /etc/sysconfig/rtirq
in Fedora and /etc/default/rtirq
in Ubuntu. If you use a USB sound card, you may want to put “usb” in front of “snd” in the RTIRQ_NAME_LIST in rtirq's configuration file (or remove “snd”) to give your USB sound card higher priority than your onboard sound card.
To set IRQ priorities manually, see this guide.
CPU frequency scaling is a main cause of Mixxx skipping on laptops. You can disable it by running this shell script as root:
for i in /sys/devices/system/cpu/cpu[0-9]*; do echo performance >$i/cpufreq/scaling_governor; done
Alternately, you can use the cpupower
utility: sudo cpupower frequency-set -g performance
.
The CPU governor will be reset when rebooting your computer. To run this every time your computer boots, save the above shell script to /etc/rc.d/rc.local and set that file to be executable chmod +x /etc/rc.d/rc.local
(this should work even on distributions using systemd). Note that this will run through your battery's charge much faster.
This utility polls for smart cards every few seconds, and when it does, it can cause Mixxx's audio to skip, even with the latency set really high.
For more tips, see Windows Tuning Tips for Audio Processing from Native Instruments (this information applies to versions of Windows newer than Vista as well).
Raise the priority of Mixxx. While Mixxx is running, open Terminal and run sudo renice -20 `pidof mixxx`
(your user must be in /etc/sudoers
).
If you know of any more tips for reducing audio latency on macOS, please edit this page and add them here.