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:
Simultaneous Multithreading (SMT), or HyperThreading (HT) as Intel calls it, can make some programs faster but makes realtime audio software like Mixxx much more likely to glitch. Most modern computers have SMT enabled by default. On some computers, it can be disabled in the BIOS/EFI firmware settings when booting your computer. These settings can be accessed by pressing a key as the computer is turning on. Which key you need to press is different on every computer, so watch if it says on screen or refer to the computer manufacturer's documentation. Unfortunately some computers do not have an option to disable SMT/HyperThreading in the BIOS/EFI settings. On these computers, SMT can still be disabled when using Linux by setting the “nosmt” kernel parameter as described below.
SMT makes the CPU appear to the OS as if each physical CPU core was 2 cores (thus a dual core processor seems like it has 4 cores or a quad core processor seems like it has 8 cores). This allows two threads to switch off between using one CPU core, which may be beneficial for software that makes heavy use of parallel processing. However, realtime audio software like Mixxx requires reliable, uninterrupted time to use the CPU to avoid audio glitches (xruns). When two threads share the same CPU core with SMT, it is much more likely that Mixxx (or other realtime audio software) will not generate the audio it needs in time so you and your audience will hear a glitch.
First, try disabling HyperThreading/SMT by turning it off in your computer's BIOS/EFI settings as described above. If that option is not available on your computer, SMT can be disabled by Linux by adding “nosmt” to the kernel boot parameters. How to do this may vary depending on your distribution, so refer to your distribution's documentation for details. On Fedora, edit the text file /etc/default/grub as root. There should be a line that shows something like:
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/root rd.luks.uuid=luks-8847b15d-fd3c-4b93-a107-1e5166685508 rd.lvm.lv=fedora/swap rhgb quiet"
Add the “nosmt” parameter to the end of this:
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/root rd.luks.uuid=luks-8847b15d-fd3c-4b93-a107-1e5166685508 rd.lvm.lv=fedora/swap rhgb quiet nosmt"
Then, regenerate your GRUB configuration file:
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
On other distributions, use “grub-mkconfig” instead of “grub2-mkconfig” and the file path grub.cfg (after the “-o”) will change as well. Then reboot your computer.
SMT can also be toggled while Linux is running with the command:
echo off > /sys/devices/system/cpu/smt/control
but this will be reset when you reboot unless you change the kernel boot options as described above. You can also use
echo on > /sys/devices/system/cpu/smt/control
to turn it back on if you want to test the impact of having it on versus off.
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_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,
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
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
If you know of any more tips for reducing audio latency on macOS, please edit this page and add them here.