Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
wiki:system_configuration [2017/05/29 12:14] – [The kernel] autostaticwiki:system_configuration [2024/01/13 15:00] (current) – [Priorities] autostatic
Line 6: Line 6:
  
 ===== How do I build a real-time audio workstation on Linux? ===== ===== How do I build a real-time audio workstation on Linux? =====
 +
 +The [[https://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/|Ardour manual]] has a interesting introduction about getting the right computer system for digital audio. Below that article there is also a (somewhat Windows oriented) [[https://www.youtube.com/watch?v=GUsLLEkswzE| video]] by Richard Ames, which could be helpful to get a idea which things are involved for this topic. Summary: lots of things are involved for a well performing real-time audio workstation. It's not simply a matter of buying a computer with massive CPU and memory power, as the coming sections on this page shows.
 +
 +A good starting point for optimizing your system for real-time audio on GNU/Linux, is the [[system_configuration#rtcqs]] script below.
 +
 +After adjusting your system using the recommendations of [[system_configuration#rtcqs]] and with JACK (QjackCtl) and a2jmidid installed, the basics should be there for a well performing real-time audio system (depending on your hardware too of course).
 +
 +This wiki also contains a manual on installing a Linux audio system here: [[wiki:system_build|]]
 +
 ==== Preliminary ==== ==== Preliminary ====
  
Line 15: Line 24:
 This way you can restore the original file in the case you made such a typo that the system has become unbootable. The procedure of recovering an unbootable system itself is beyond the scope of this Wiki but there are plenty of resources that explain this in detail. This way you can restore the original file in the case you made such a typo that the system has become unbootable. The procedure of recovering an unbootable system itself is beyond the scope of this Wiki but there are plenty of resources that explain this in detail.
  
-==== QuickScan ==== 
- 
-The [[https://github.com/raboof/realtimeconfigquickscan|realTimeConfigQuickScan]] script automatically analyzes your current configuration. This script will make configuration suggestions based on your current setup and link to the relevant sections on this page for background information. 
- 
-To get the script install [[http://en.wikipedia.org/wiki/Git_%28software%29|Git]] first and then pull in the script: 
-  git clone git://github.com/raboof/realtimeconfigquickscan.git 
-  cd realtimeconfigquickscan 
-  perl ./realTimeConfigQuickScan.pl 
- 
-Discuss this script at the [[http://linuxmusicians.com/viewtopic.php?f=27&t=452|LinuxMusicians Forum]] 
  
 ==== The kernel ==== ==== The kernel ====
Line 30: Line 29:
 === Note about kernels === === Note about kernels ===
  
-  * Kernels >= 2.6.31 seem to work pretty good without RT patch, also for real-time pro audio usage. It's not strictly necessary anymore to install a real-time ('rt') kernel to get good results. Although the best results are still expected when using a real-time kernel. Try it, test it and decide for yourself.  +  * Modern kernels work pretty well without the RT patch, also for real-time pro audio usage. It's not strictly necessary anymore to install a real-time ('rt') kernel to get good results. Although the best results are still expected when using a real-time kernel. Try it, test it and decide for yourself.  
-  * In the pre-2.6.39 kernel era rt kernels were indeed necessary in some cases where sound devices were sharing IRQ's with other peripherals. With the rt kernel and the rtirq script you could prioritize IRQ threads but since 2.6.39 it is possible to use the rtirq kernel with a generic kernel and the ''threadirqs'' kernel option. +  * With the rt kernel and the rtirq script you could prioritize IRQ threads but with a modern kernel it is possible to use the rtirq script with a generic kernel and the ''threadirqs'' kernel option. 
-  * Many distro kernels, and many third-party-provided real-time kernels, are configured without the 1000 Hz setting.  This is not significant for recordingbut it can be an issue for live MIDI work if the application you're using does not rely on the ''snd-hrtimer'' kernel module.  If your application is live MIDI, using ALSA MIDI and relies on ''/dev/rtc'' (so it doesn't rely on the ''snd-hrtimer'' kernel module), you may well want real-time, but you certainly need 1000 Hz.+  * Many distro kernels, and many third-party-provided real-time kernels, are configured without the 1000 Hz setting. As modern audio software relies on high resolution timers this is not a problem anymore, you really don't need to set the kernel timer frequency other than the default.
  
 === Status of your kernel === === Status of your kernel ===
Line 38: Line 37:
 Run ''uname -a'' to find out which kernel you're running: Run ''uname -a'' to find out which kernel you're running:
  
-  Linux xps13 4.8.15-core2-rt10 #1 SMP PREEMPT RT Sun May 28 10:43:44 CEST 2017 x86_64 x86_64 x86_64 GNU/Linux+  Linux bto 6.5.6-1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 6.5-7.1~bookworm (2023-10-06) x86_64 GNU/Linux
  
-4.8.15-core2-rt10 is the version number of the currently running kernel. The configuration file with which this kernel was created can be found in ''/boot/config-4.8.15-core2-rt10''. Open it, and check if it has the following characteristics:+6.5.6-1-liquorix-amd64 is the version number of the currently running kernel. The configuration file with which this kernel was created can be found in ''/boot/config-6.5.6-1-liquorix-amd64''. Open it, and check if it has the following characteristics:
  
-  CONFIG_HZ_1000=y +  CONFIG_HIGH_RES_TIMERS=y 
-  CONFIG_HZ=1000 +  CONFIG_NO_HZ_IDLE=y 
-  CONFIG_PREEMPT_RT_FULL=y +  CONFIG_PREEMPT=y # low-latency kernel 
-  CONFIG_PREEMPT=y+  CONFIG_PREEMPT_RT=y # real-time kernel
  
-The "RT" is real-time, and the above reflects a real-time kernel.  The "1000" reflects the 1000 Hz setting.  +''CONFIG_HIGH_RES_TIMERS=y'' indicates your kernel has high resolution timer supportthe ''CONFIG_NO_HZ_IDLE'' means your kernel is tickless and the ''CONFIG_PREEMPT'' options indicate you're either running a low-latency kernel (''CONFIG_PREEMPT'') or a real-time kernel (''CONFIG_PREEMPT_RT_FULL'').
  
-If you can't find the config file for your kernel there is also the possibility to extract the config from ''/proc/config.gz'' if your kernel supports it (CONFIG_IKCONFIG_PROC=y): +If you can't find the config file for your kernel there is also the possibility to extract the config from ''/proc/config.gz'' if your kernel supports it (''CONFIG_IKCONFIG_PROC=y''): 
-  cat /proc/config.gz | gunzip > config-`uname -r+  gunzip -c /proc/config.gz > config-$(uname -r)
-   +
-The Quickscan is also good for checking if you have a RT kernel and if the kernel timer setting is adequate.+
  
 === Do I really need a real-time kernel? === === Do I really need a real-time kernel? ===
  
-As of kernel 2.6.39 one the core parts of the real-time patchset, threaded IRQs, has been integrated into the main kernel. With the kernel boot option ''threadirqs'' standard kernels create threaded IRQs, a feature that was reserved to kernels < 2.6.39 patched with the real-time patch-set. Read more about threaded IRQs [[system_configuration#priorities|here]]. The integration of this feature into the main kernel basically nullifies the need to use a real-time kernel in most of the cases. But a real-time kernel can still be very useful on a Linux audio platform. If you need the lowest latencies possible and tight timing (for live MIDI applications for instance) a real-time kernel might still be your best resort. But if you're mainly recording, a standard kernel or an optimized kernel (like the low-latency kernel Ubuntu offers) will suffice probably.+With the kernel boot option ''threadirqs'' standard kernels create threaded IRQs which basically nullifies the need to use a real-time kernel in most of the cases. But a real-time kernel can still be very useful on a Linux audio platform. If you need the lowest latencies possible or if you're working on a less powerful system (i.e. Raspberry Pi) a real-time kernel can still be an option. But if you're mainly recording, a standard kernel or an optimized kernel (like the low-latency kernel Ubuntu offers) will probably suffice. 
 + 
 +See also: [[https://jackaudio.org/faq/realtime_vs_realtime_kernel.html|Do I need a realtime kernel to use realtime scheduling?]]
  
 === Using the threadirqs kernel option === === Using the threadirqs kernel option ===
  
-This is only needed for so-called generic kernels, ie. standard kernels that are not tweaked for lowlatency performance. You can check if your kernel already includes this option with the following command:+This is only needed for so-called generic or low-latency kernels. You can check if your kernel already includes this option with the following command:
  
-  $ grep -e "CONFIG_IRQ_FORCED_THREADING=y" -e "CONFIG_PREEMPT=y" /boot/config-`uname -r`+  $ grep -e "CONFIG_IRQ_FORCED_THREADING=y" -e "CONFIG_PREEMPT_RT=y" /boot/config-$(uname -r)
    
-If it returns ''CONFIG_IRQ_FORCED_THREADING=y'' and ''CONFIG_PREEMPT=y'' then your kernel is using IRQ threading and you don't have to proceed with the following steps. If it only returns ''CONFIG_IRQ_FORCED_THREADING=y'' you can add the ''threadirqs'' boot option as described below. If the command returns nothing you have a kernel that cannot use threaded IRQs.+If it returns ''CONFIG_IRQ_FORCED_THREADING=y'' and ''CONFIG_PREEMPT_RT=y'' then your kernel is using IRQ threading and you don't have to proceed with the following steps. If it only returns ''CONFIG_IRQ_FORCED_THREADING=y'' you can add the ''threadirqs'' boot option as described below. If the command returns nothing you have a kernel that cannot use threaded IRQs.
  
 Open ''/etc/default/grub'' with your favorite editor as root. Open ''/etc/default/grub'' with your favorite editor as root.
Line 74: Line 73:
  
 Now reboot and you should have threaded IRQs. Now reboot and you should have threaded IRQs.
 +
 +=== Disabling Spectre and Meltdown mitigations ===
 +:!: Warning: Using ''mitigations=off'' will make your machine less secure! Use with caution! For more information on the risks see https://meltdownattack.com/
 +
 +To work around the Spectre and Meltdown vulnerabilities several mitigations were built into the kernel. These mitigations can have a negative impact on the performance of your machine. To disable those mitigations and get the most out of your CPU's again you can add the following kernel parameter to your Grub configuration, add it to the value of either ''GRUB_CMDLINE_LINUX_DEFAULT'' or  ''GRUB_CMDLINE_LINUX'':
 +
 +  mitigations=off
  
 === Installing a real-time kernel === === Installing a real-time kernel ===
  
-This section describes installing a real-time kernel on an existing Linux distribution. Some distributions contain packages you can install to get a real-time kernel, for others you'll need to compile it yourself. You can recognize real-time kernel versions by the added '-rt' or '-realtime' parts of the kernel version number.+This section describes installing a real-time kernel on an existing Linux distribution. Some distributions contain packages you can install to get a real-time kernel, for others you'll need to compile it yourself. You can recognize real-time kernel versions by the added '-rt' or '-realtime' parts of the kernel version number. As mentioned earlier, a real-time kernel is not a mandatory part of a Linux audio setup.
  
 == Ubuntu == == Ubuntu ==
  
-Ubuntu Studio 12.04 comes with a 1000 Hz non-real-time low-latency kernel. Unfortunately there are no packaged real-time kernels available but using [[system_configuration#build_your_own_real-time_kernel|the kernel build method described in this Wiki]] it should be fairly easy to build your own real-time kernel((http://askubuntu.com/questions/72964/how-can-i-install-a-realtime-kernel)).+Ubuntu Studio comes with a non-real-time low-latency kernel. Unfortunately there are no packaged real-time kernels available but using [[system_configuration#build_your_own_real-time_kernel|the kernel build method described in this Wiki]] it should be fairly easy to build your own real-time kernel((http://askubuntu.com/questions/72964/how-can-i-install-a-realtime-kernel)).
  
 == Debian == == Debian ==
  
-Since Debian Wheezy an RT variant is also available in the [[https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=linux-image-rt|stock repositories]]; unfortunately its system timer is set to 250 Hz instead of 1000 Hz, so you'll probably want to recompile your own kernel anyway, especially if you use ALSA MIDI. These kernels incorporate [[http://pengutronix.de/software/linux-rt/debian_en.html|Pengutronix]] patches (see [[https://wiki.debian.org/DebianMultimedia#Realtime_kernel|DebianMultimedia Wiki]]). The [[http://www.64studio.com/|64 Studio]] real-time kernels are in the backports apt repository, so for Debian Squeeze you will have to add the following line to your apt sources list: +Since Debian Wheezy an RT variant is also available in the [[https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=linux-image-rt|stock repositories]]. These kernels incorporate [[http://pengutronix.de/software/linux-rt/debian_en.html|Pengutronix]] patches (see [[https://wiki.debian.org/DebianMultimedia#Realtime_kernel|DebianMultimedia Wiki]]).
- +
-  deb http://apt.64studio.com/backports squeeze-backports main+
  
 == Arch == == Arch ==
Line 95: Line 99:
 == Gentoo == == Gentoo ==
  
-RT kernels are vailable in the pro-audio overlay (http://proaudio.tuxfamily.org/wiki/index.php?title=Main_Page).+An audio overlay can be found here [[https://github.com/gentoo-audio/audio-overlay]].
  
 === Build your own real-time kernel === === Build your own real-time kernel ===
  
-If your distribution isn't any helpyou can compile and install a real-time kernel manually. The examples assume building a RT kernel based on the 3.2 kernel version but they should generally apply fo other kernel versions too provided that there is a RT patchset available for the used kernel+For rolling your own kernelsee [[build_your_own_real-time_kernel]].
  
-Install the necessary packages, on Debian and Ubuntu this is: +=== Other alternatives === 
-  sudo apt-get install kernel-package fakeroot build-essential +Besides low-latency or real-time kernels there are also other kernel flavors available specifically tailored for multimedia usage.
- +
-Download the kernel sources and the RT patchset (this example uses the 3.18 branch, you're free to use another kernel branch for which there is a RT patch set available): +
-  mkdir -p ~/tmp/linux-rt +
-  cd ~/tmp/linux-rt +
-  wget -c https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.18.7.tar.xz +
-  wget -c https://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.7-rt1.patch.xz +
- +
-Extract the kernel sources and patch them with the RT patchset: +
-  tar xJvf linux-3.18.7.tar.xz +
-  cd linux-3.18.7 +
-  xzcat ../patch-3.18.7-rt1.patch.xz | patch -p1 +
- +
-Now you need to configure the kernel. The easiest way is to use an existing kernel config, those configs can be found in the ''/boot/'' directory of your system. You can copy an appropriate kernel config to your current working directory and use that config as a starting point: +
-  cp /boot/config-`uname -r` .config +
- +
-This will copy the config of the kernel you're currently using. You might want to consider using a config of a kernel already optimized for audio work, like the Ubuntu -lowlatency  kernel config. +
-The next step is to create a new config with full preemption enabled from the copied config: +
-  make oldconfig +
- +
-You will get a lot of prompts but you can leave everything at its default value except for the prompt which Preemption Model you'd like to use. Select option 5 there (Fully Preemptible Kernel): +
-  Preemption Model +
-  > 1. No Forced Preemption (Server) (PREEMPT_NONE) +
-    2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY) +
-    3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT__LL) (NEW) +
-    4. Preemptible Kernel (Basic RT) (PREEMPT_RTB) (NEW) +
-    5. Fully Preemptible Kernel (RT) (PREEMPT_RT_FULL) (NEW) +
-  choice[1-5]: 5 <Enter> +
- +
-You can use one of these commands to edit the configuration: +
-  make config +
-if you want a text interface, or +
-  make menuconfig +
-for a nice ncurses text interface (you need to install libncurses5-dev if you're on Debian or Ubuntu), or +
-  make nconfig +
-for another ncurses interface with better keybindings, or +
-  make xconfig +
-for a qt GUI interface (you need to install libqt4-dev if you're on Debian or Ubuntu). +
- +
-Make sure to check the "''Timer Frequency: 1000 Hz''" options under the "''Processor type and features''" group. +
- +
-When your configuration is done, you can build and install the kernel and its modules (distro-agnostic way): +
-  make +
-  make install +
-  make modules_install +
- +
-On Debian or Ubuntu the building step can be done like this: +
-  make -j `nproc` LOCALVERSIONdeb-pkg +
- +
-Or if you prefer make-kpkg: +
-  CONCURRENCY_LEVEL=`nproc` LOCALVERSIONfakeroot make-kpkg --initrd kernel_image kernel_headers +
- +
-You can also use ''`getconf _NPROCESSORS_ONLN`'' instead of ''`nproc`''+
- +
-When building is complete and the packages have been created you can install them (this will also update the boot loader menu): +
-  cd .. +
-  sudo dpkg -i linux-{headers,image}-3.18.7-rt1_*.deb +
-   +
-If you built and installed the kernel the distro-agnostic way you will have to update the bootloader yourself: +
-  sudo update-grub +
-   +
- +
-== Optional bits == +
- +
-You may want to disable the debug features; this will save compile space. You can do it in the config interface, or from the shell with this command: +
-  scripts/config --disable DEBUG_INFO +
-   +
-You may want to set the "''Local version''" (in the "''General setup''" group) to your name or ''-custom-rt'' or whatever: it will be appended to the kernel name so you'll easily recognize it as a custom build, and you won't risk overwriting some working kernel with the same name. You can achieve the same result by editing the file ''localversion-rt'' and append a local version name to the version number of the RT patch set. +
-  +
-You can do without an initrd if you build into the kernel (not as a module, i.e. checked in the config as "''*''" and not "''m''") everything you need to boot (e.g. ext4, chipset drivers, keyboard drivers, etc.). If you need it, build it with: +
-  mkinitrd -k kernel-<kernel version> -i initrd-<kernel version> +
-or follow your distro guide. +
- +
-If you need to know which drivers you need for your hardware, use the form at http://kmuto.jp/debian/hcl/ (it's distro-agnostic, even if it says "Debian" everywhere). +
- +
-== Build your own real-time kernel on Debian Wheezy or later == +
- +
-Since Debian Wheezy, the linux-source-3.2 package already installs the RT patch (you don't need to download it from upstream), but you'll have to apply it manually. +
- +
-(Instructions taken from http://kernel-handbook.alioth.debian.org/ch-common-tasks.html). +
- +
-Install the kernel source package: +
-  sudo aptitude install linux-source +
-This installs a linux tarball and a bzipped RT patch in /usr/src/ . Copy them to wherever you want to build (you'll need some GB of free space), untar/bunzip them and cd into the linux source directory. +
- +
- +
-Apply the RT patch: +
-  patch -p1 -i ../linux-patch-3.x-rt.patch +
- +
- +
-Make sure to install the needed tools for the build: +
-  sudo apt-get build-dep linux +
- +
- +
-Now you must configure the kernel. +
-(This step is distro-agnostic, you can follow the istructions in the [[system_configuration#build_your_own_real-time_kernel|previous paragraph]]). +
- +
- +
-Then you can compile... +
-  make clean +
-  make deb-pkg +
- +
-... and install the new kernel +
-  sudo dpkg -i ../linux-image-3.x.yy_foo.deb+
  
 +== Liquorix ==
 +> Liquorix is an enthusiast Linux kernel designed for uncompromised responsiveness in interactive systems, enabling low latency compute in A/V production, and reduced frame time deviations in games.((https://liquorix.net/))
 +Especially when used in combination with the ''threadirqs'' kernel option this kernel flavor performs very well. It is also the kernel that drives [[https://www.bandshed.net/avlinux/|AV Linux]].
  
 == Other relevant links == == Other relevant links ==
  
-  * https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO +  * https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/preemptrt_setup 
-  * Forum thread: http://linuxmusicians.com/viewtopic.php?f=27&t=10058 +  * Forum thread: https://linuxmusicians.com/viewtopic.php?f=27&t=10058 
-  * [[http://proaudio.tuxfamily.org/wiki/index.php?title=Realtime_(RT)_Kernel]] +  * https://gentoostudio.org/?page_id=420 
-  * http://proaudio.tuxfamily.org/wiki/index.php?title=DAW_Digital_Audio_Workstation +  * https://joegiampaoli.blogspot.com/2011/06/m-audio-fast-track-pro-for-debian-linux.html
-  * http://gentoostudio.org/?p=maninstall&s=kernel +
-  * http://joegiampaoli.blogspot.de/2011/06/m-audio-fast-track-pro-for-debian-linux.html +
-  * http://users.wowway.com/~zlinuxman/Kernel.htm +
-  * http://kernel-handbook.alioth.debian.org/+
  
 ==== Disabling resource-intensive daemons, services and processes ==== ==== Disabling resource-intensive daemons, services and processes ====
Line 223: Line 123:
 You should check if the following daemons, services or processes are running, and if so, consider stopping them and/or resort to alternatives: You should check if the following daemons, services or processes are running, and if so, consider stopping them and/or resort to alternatives:
  
-  * powersaved +  * CPU frequency scaling daemons that scale the frequency of the CPU depending on the CPU load could cause xruns in some cases. More recent versions of Jack1 (>= 0.118.0) are suffering less from xruns or run xrun free with a CPU frequency scaling daemon enabled that's set to a scaling governor like ondemand. A specialized CPU scaling daemon is in the works that depends on the DSP-load instead of the CPU load: [[http://rg42.org/oss/jackfreqd/start|jackfreqd]].
-  * kpowersave +
-  * upowersave ? +
-  * CPU frequency scaling daemons that scale the frequency of the CPU depending on the CPU load could cause xruns in some cases. More recent versions of Jack1 (>= 0.118.0) are suffering less from xruns or run xrun free with a CPU frequency scaling daemon enabled that's set to a scaling governor like ondemand. A specialized CPU scaling daemon is in the works that depends on the DSP-load instead of the CPU load: [[http://rg42.org/oss/jackfreqd/start|jackfreqd]] +
-  * Debian/Ubuntu: a default install will have the apt-xapian-index package installed that enables the Quick Search option in the Synaptic package manager. In order for this Quick Search functionality to work properly it needs to regularly update its database with the help of a cronjob. Especially on less powerful machines this cronjob could cause major xruns. Consider uninstalling the apt-xapian-index package.+
   * Desktop Environments (DE): especially on less powerful machines it is recommended to use a lighter DE than Gnome, KDE or Unity. Possible alternatives include LXDE, XFCE or IceWM. Another option is to only use a lightweight Window Manager (WM) like Openbox or Fluxbox.   * Desktop Environments (DE): especially on less powerful machines it is recommended to use a lighter DE than Gnome, KDE or Unity. Possible alternatives include LXDE, XFCE or IceWM. Another option is to only use a lightweight Window Manager (WM) like Openbox or Fluxbox.
   * Compositing: same recommendation as for the DE you use. Try to avoid using a compositing manager like Compiz to lower the chance of running into xruns.   * Compositing: same recommendation as for the DE you use. Try to avoid using a compositing manager like Compiz to lower the chance of running into xruns.
   * Gnome NetworkManager and WiFi: NetworkManager keeps scanning for new wireless networks in the background and this might cause xruns. The best option is to not use a wireless network manager in a low-latency real-time audio environment. If you really can't do without WiFi you probably won't have another option than to use wpa_supplicant.   * Gnome NetworkManager and WiFi: NetworkManager keeps scanning for new wireless networks in the background and this might cause xruns. The best option is to not use a wireless network manager in a low-latency real-time audio environment. If you really can't do without WiFi you probably won't have another option than to use wpa_supplicant.
-  * NTP: there are reports of NTP interfering with FFADO, so if you're using a FireWire audio device make sure you disable the ntpd service and any cronjob or ifup script that tries to sync your local clock with an NTP server. This issue is resolved in the 2.1.0 release of FFADO. 
  
-==== CPU frequency scaling ====+=== CPU frequency scaling ===
  
 If your CPU supports frequency scaling and the CPU frequency scaling governor is set to //ondemand// (which is the default on a lot of distros) you could run into xruns. The //ondemand// governor scales the frequency according to the CPU load, the more the load, the higher the frequency. But this is happening independently from the DSP load on your system so it could happen that the DSP load suddenly rises for instance, demanding more CPU power, and that the scaling daemon kicks in too late, resulting in xruns because the DSP load maxes out. A solution would be to use a CPU frequency scaling daemon that scales the frequency according to the DSP load on your system like [[http://rg42.org/oss/jackfreqd/start|jackfreqd]] or to simply disable CPU frequency scaling altogether. The latter can be achieved by setting the scaling governor to //performance//. If your CPU supports frequency scaling and the CPU frequency scaling governor is set to //ondemand// (which is the default on a lot of distros) you could run into xruns. The //ondemand// governor scales the frequency according to the CPU load, the more the load, the higher the frequency. But this is happening independently from the DSP load on your system so it could happen that the DSP load suddenly rises for instance, demanding more CPU power, and that the scaling daemon kicks in too late, resulting in xruns because the DSP load maxes out. A solution would be to use a CPU frequency scaling daemon that scales the frequency according to the DSP load on your system like [[http://rg42.org/oss/jackfreqd/start|jackfreqd]] or to simply disable CPU frequency scaling altogether. The latter can be achieved by setting the scaling governor to //performance//.
Line 243: Line 138:
   echo -n performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor   echo -n performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
  
-You could also add line to your ''/etc/rc.local'' file for instance to set the governor to //performance// at boot time+You could create Systemd Unit that does this for youExample of an rt-audio-setup Unit file, create as /etc/systemd/system/rt-audio-setup.service
-  echo -n performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor+  [Unit] 
 +  Description=Prepare system for real-time audio 
 +   
 +  [Service] 
 +  Type=oneshot 
 +  ExecStart=/bin/bash /usr/local/bin/rt-audio-setup 
 +  RemainAfterExit=yes 
 +   
 +  [Install] 
 +  WantedBy=multi-user.target
  
-=== Ubuntu ===+This will start ''/usr/local/bin/rt-audio-setup'' at boot so you can add the aformentioned line regarding setting the CPU's to the //performance// scaling governor there, make the file executable, enable the Systemd service and start it. 
 +  echo 'echo -n performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor' | sudo tee /usr/local/bin/rt-audio-setup 
 +  sudo chmod +x /usr/local/bin/rt-audio-setup 
 +  sudo systemctl enable rt-audio-setup 
 +  sudo systemctl start rt-audio-setup
  
-On Ubuntu systems the command in your ''/etc/rc.local'' file only works if you disable the ondemand service: +The ''rt-audio-setup'' script could then also be used to set up other things.
-  sudo update-rc.d ondemand disable +
-  +
-Another option would be to modify the ''ondemand'' init script and rename it to ''performance'': +
-  sudo sed -i 's/ondemand/performance/g' /etc/init.d/ondemand +
-  sudo update-rc.d ondemand disable +
-  sudo cp /etc/init.d/ondemand /etc/init.d/performance +
-  sudo update-rc.d performance defaults+
  
-=== Debian ===+== Ubuntu == 
 + 
 +On Ubuntu systems the command in ''/usr/local/bin/rt-audio-setup'' file only works if you disable the ondemand service: 
 +  sudo systemctl mask ondemand.service 
 + 
 +== Debian ==
  
 On Debian you can control the scaling governor with the ''cpufreq-set'' utility which is part of the ''cpufrequtils'' package: On Debian you can control the scaling governor with the ''cpufreq-set'' utility which is part of the ''cpufrequtils'' package:
Line 268: Line 174:
   MIN_SPEED="0"    MIN_SPEED="0" 
  
-=== BIOS ===+== BIOS ==
  
 Most BIOSes allow to disable CPU frequency scaling altogether and as a result your CPU will run at its maximum clock rate. For Intel CPUs you should look for a [[http://en.wikipedia.org/wiki/SpeedStep|SpeedStep]] option. Its AMD equivalents are either [[http://en.wikipedia.org/wiki/Cool%27n%27Quiet|Cool'n'Quiet]] or [[http://en.wikipedia.org/wiki/PowerNow!|PowerNow!]].  Most BIOSes allow to disable CPU frequency scaling altogether and as a result your CPU will run at its maximum clock rate. For Intel CPUs you should look for a [[http://en.wikipedia.org/wiki/SpeedStep|SpeedStep]] option. Its AMD equivalents are either [[http://en.wikipedia.org/wiki/Cool%27n%27Quiet|Cool'n'Quiet]] or [[http://en.wikipedia.org/wiki/PowerNow!|PowerNow!]]. 
Line 277: Line 183:
  
 With these settings disabled the //ondemand// governor should work without causing any xruns. With these settings disabled the //ondemand// governor should work without causing any xruns.
- 
-==== Disabling problematical services and other hidden bits ==== 
- 
-=== Types of things to disable === 
- 
-There are several different types of things which can be helpful to disable.  But within all of the types, are likely to be items which you will need for a working machine!  So do be careful. 
- 
-  * System services using the SysV / rc.d / init.d standards.   
-  * System services using the newer 'upstart' standard.   
-  * DBus-initiated processes.   
-  * Hardware support modules. 
-  * GUI login session startup items. 
- 
-=== System services using SysV / rc.d / init.d. === 
- 
-Many distros still use this exclusively.  Command-line tools for disabling these are update-rc.d and chkconfig.  On most distros which use these, you'll need the concept of the "runlevel"; a runlevel is a level at which the system can be run, and each runlevel has its own set of services.  The older standard was to have separate runlevels for single-user mode for debugging, text-mode only, X, etc., but there is a lot of variation on this now, rather distro-specific. 
- 
-=== System services using upstart. === 
- 
-Upstart is quite new, fast, and commended by much of the Linux devel community.  Ubuntu 12.04 uses a combination of SysV and upstart, and its community is undergoing a migration towards upstart only.  To disable services controlled by upstart, go to the folder /etc/init (not /etc/init.d, that's SysV), find the name of the config file corresponding to an item you want disabled (e.g., bluetooth.conf), create a corresponding file of extension .override (in this case, bluetooth.override).  The .override file needs to contain just the one line "manual" Reboot to implement the change. 
- 
-=== DBus-controlled services === 
- 
-DBus is a solid standard used for a wide variety of services which need to be started automatically, but on demand only, in the background, not specifically at boot.  One set of DBus services used extensively in Ubuntu is 'gvfs', the virtual filesystem for the Gnome desktop; if these are permitted to run, polling of hardware including the USB bus will occur, which is likely to interfere with USB MIDI interfaces, eat CPU power, and cause xruns in general.  To disable gvfs, go as root to /usr/share/dbus-1/services , rename gvfs-daemon.service to gvfs-daemon.service.disabled, and rename gvfs-metadata.service to gvfs-metadata.service.disabled.   
  
 === Hardware support modules === === Hardware support modules ===
Line 306: Line 188:
 These are modules in the Linux kernel which support various hardware.  All of them will reserve resources.  If, for instance, you have an HDMI audio port which you don't need, you can blacklist it to disable it.  However, you should check the IRQ usage first (see related section of this document), because this might be the more vital change to make, if you do in fact have a conflict. These are modules in the Linux kernel which support various hardware.  All of them will reserve resources.  If, for instance, you have an HDMI audio port which you don't need, you can blacklist it to disable it.  However, you should check the IRQ usage first (see related section of this document), because this might be the more vital change to make, if you do in fact have a conflict.
  
-==== Example script for needed disables ====+=== Example script to disable resource-intensive daemons, services and processes ===
  
 There are quite some processes and drivers running that you might not need when making music. Below an extremely simple example of a Bash script to disable all unneeded things.  Note that it includes a solution for IRQ conflict, documented further down. There are quite some processes and drivers running that you might not need when making music. Below an extremely simple example of a Bash script to disable all unneeded things.  Note that it includes a solution for IRQ conflict, documented further down.
  
-  #!/bin/sh+:!: The script below is an example, do not use as is but first adapt it to your own system 
 + 
 +  #!/bin/bash
      
-  modprobe -r ppdev I don't have a parallel port +  # Remove unneeded kernel modules 
-  modprobe -r lp # I don't use a printer when making music +  modules="module1 module2 module3"
-  modprobe -r uvcvideo # I don't use a webcam when making music +
-  modprobe -r videodev # Ditto +
-  modprobe -r ath9k # Wireless driver +
-  modprobe -r r8169 # NIC driver +
-  modprobe -r btusb # Bluetooth USB+
      
-  /etc/init.d/bluetooth stop & # Stop Bluetooth related processes +  for module in $modules; do 
-  /etc/init.d/cups stop & # Stop cups, I don't use a printer when making music +    modprobe -r $module 
-  /etc/init.d/networking stop & # Stop networking, the internet is a very distracting factor when making music +  done
-  /etc/init.d/network-manager stop & # Ditto+
      
-  killall modem-manager I don't have a modem +  # Unbind Bluetooth 
-  killall wpa_supplicant # See the network stuff above+  echo -n "2-1.6" > /sys/bus/usb/drivers/usb/unbind
      
-  modprobe snd-hrtimer Load the ALSA high res timer for my MIDI stuff+  # Disable CPU frequency scaling 
 +  systemctl mask ondemand
      
-  echo -n performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # Set the CPU scaling governor to performance +  # Set scaling governor to performance 
-   +  echo -n performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
-  echo -n "0000:00:13.0"/sys/bus/pci/drivers/ohci_hcd/unbind # Unbind a USB port, this one interferes with my onboard soundcard +
-   +
-  # The following section is for kernels < 2.6.39. Kernels > 2.6.39 do not have a tasklet daemon. +
-  TASKLETPR=76 # Define a variable TASKLETPR and set it to 76 +
-   +
-  ps -eLo pid,cmd | grep [t]asklet | awk 'system("chrt -f -p '$TASKLETPR' " $1)}' # Do some greppy awky stuff and set the prio of the tasklet daemon +
- +
-You could run this script once you're logged in (it needs root privileges though), run it from ///etc/rc.local// or even as an init script. A suggestion would be to run it only when a real-time kernel is loaded for example:+
  
-  if [ $(uname -r | cut -d "-" -f 3) = "realtime"+You could run this script once you're logged in (it needs root privileges though) or run it at boot, see the rt-audio-setup suggestion above
-  then /path/to/the/above/script +
-  fi+
    
 The modules and processes differ of course on a per machine basis so first figure out which modules are loaded with ''lsmod'' for instance and then decide which ones you really need. Same for any processes running on your machine, ''ps -ef'' or even ''pstree -p'' could be helpful when looking for unneeded processes. The modules and processes differ of course on a per machine basis so first figure out which modules are loaded with ''lsmod'' for instance and then decide which ones you really need. Same for any processes running on your machine, ''ps -ef'' or even ''pstree -p'' could be helpful when looking for unneeded processes.
Line 403: Line 272:
 More information: http://lwn.net/Articles/143397/ More information: http://lwn.net/Articles/143397/
  
 +==== Power management ====
 +=== Quality of Service interface ===
 +The Linux kernel provides a user mode interface for registering performance expectations((https://www.kernel.org/doc/html/latest/power/pm_qos_interface.html)). One of the parameters it could work on is CPU latency. A modern CPU can have different so-called sleep states and waking up from those sleep states can take some time (CPU latency). By opening the device node ''/dev/cpu_dma_latency'' and registering a value with it you can control these CPU
 + latencies. I.e. when registering the value 0 you can tell the CPU to never go to sleep and to always be avialable, without any latency. In some cases this can decrease DSP load and in its turn decrease the chance of running into xruns. In order for this to work the device node has to be kept open with the registered value, simply writing a value to it will not work. DAW's like Ardour and Reaper offer the possibility to control the CPU latency and if you want to take advantage of this you will want your user to be able to write to this device node. To configure this add the udev rule from https://github.com/Ardour/ardour/blob/master/tools/udev/99-cpu-dma-latency.rules to ''/etc/udev/rules.d/'' and reload udev:
 +  sudo udevadm control --reload-rules
 +  sudo udevadm trigger
 +
 +To check if udev picked up your new rule:
 +  udevadm info -a -n /dev/cpu_dma_latency
 +
 +And ''/dev/cpu_dma_latency'' should now have read-write permissions for root and the audio group (mode 0660). Now you can set CPU latency as low as you like. Bear in mind that setting it to 0 will put your CPU's in an always-on state which wil run them hotter. So be prepared for some extra fan noise.
 ==== Filesystems ==== ==== Filesystems ====
  
-For audio use, it is desirable to use a filesystem that favours few big files over many small files and low-latency over long-term thoughput. It is said that ReiserFS and fuseblk are bad choices from this perspective, while ext3 and ext4 are good. ext4 has had some [[http://www.phoronix.com/scan.php?page=article&item=linux_perf_regressions&num=1|performance issues]] in the past but those were not directly related to processing audio and in the meanwhile most issues have been ironed out.+For audio use, it is desirable to use a filesystem that favours few big files over many small files and low-latency over long-term thoughput. It is said that ReiserFS and fuseblk are bad choices from this perspective, while ext3 and ext4 are good.
  
-In any case, it is advisable to mount ext filesystems with the ''noatime'' option enabled. This step is verified by the [[system_configuration#QuickScan]], but could use more information about which filesystems are suitable.+Ext filesystems are mounted with the ''relatime'' option by default. The ''noatime'' option could be used but the performance gain will be minimal.
  
 === SSD === === SSD ===
Line 428: Line 308:
 == noatime == == noatime ==
  
-Setting the ''noatime'' parameter in your ''/etc/fstab'' file reduces the amount of disk I/O (the inode access times are not updated each time a file is read) which could improve the overall performance of your system.+Setting the ''noatime'' parameter in your ''/etc/fstab'' file reduces the amount of disk IO (the inode access times are not updated each time a file is read) which could improve the overall performance of your system.
  
- ''/dev/sdax / ext4 noatime,errors=remount-ro 0 1''+  /dev/sdax / ext4 noatime,errors=remount-ro 0 1
  
 Most modern distributions use either ''atime'' or ''relatime''. See the mount manpage for more information on these parameters. Most modern distributions use either ''atime'' or ''relatime''. See the mount manpage for more information on these parameters.
Line 438: Line 318:
 == nobarrier == == nobarrier ==
  
-According to this thread [[http://comments.gmane.org/gmane.comp.file-systems.ext4/26720|High latency with ext4 / jbd2 kernel thread]] on the ext4 mailing list, the ''nobarrier'' parameter, with an ext4 filesystem, can reduce the amount of work made by the background kernel thread jbd2. However, it is said to be an unsafe parameter, making your filesystem less resistant to power failures. Use it with caution.+:!: This is a potentially unsafe parameter that could lead to data loss. Use with caution!
  
- ''/dev/sdax / ext4 nobarrier,errors=remount-ro 0 1''+According to this thread [[http://comments.gmane.org/gmane.comp.file-systems.ext4/26720|High latency with ext4 / jbd2 kernel thread]] on the ext4 mailing list, the ''nobarrier'' parameter, with an ext4 filesystem, can reduce the amount of work made by the background kernel thread jbd2 and increase write speeds. However, this is an unsafe parameter, making your filesystem less resistant to power failures. 
 + 
 +  /dev/sdax / ext4 nobarrier,errors=remount-ro 0 1
  
 Ext3 filesystem doesn't enable barrier by default, ext4 does. See the mount manpage for more information on these parameters. Ext3 filesystem doesn't enable barrier by default, ext4 does. See the mount manpage for more information on these parameters.
  
 == data=writeback == == data=writeback ==
 +
 +:!: This is a potentially unsafe parameter that could lead to data loss. Use with caution!
  
 >"//This option specifies the following journaling mode for file data: data may be written >"//This option specifies the following journaling mode for file data: data may be written
Line 452: Line 336:
 recovery.//"((http://elinux.org/images/b/b6/EMMC-SSD_File_System_Tuning_Methodology_v1.0.pdf)) recovery.//"((http://elinux.org/images/b/b6/EMMC-SSD_File_System_Tuning_Methodology_v1.0.pdf))
  
-You can't use this parameter in ''/etc/fstab'' for the root partition, you will have to set it as a kernel parameter. So when using Grub you can add the following parameter to the ''GRUB_CMDLINE_LINUX_DEFAULT'' line in ''/etc/default/grub'':+You can't use this parameter in ''/etc/fstab'' for the root partition, you will have to set it as a kernel parameter. So when using Grub you can add the following parameter to the ''GRUB_CMDLINE_LINUX'' line in ''/etc/default/grub'':
   rootflags=data=writeback   rootflags=data=writeback
      
-Use this parameter with caution. 
- 
 ==== limits.conf/audio.conf ==== ==== limits.conf/audio.conf ====
  
-It is advisable to set up your ///etc/security/limits.conf// or ///etc/security/limits.d/audio.conf/file properly, for example:+It is advisable to set up your ''/etc/security/limits.conf'' or ''/etc/security/limits.d/audio.conf/'' file properly, for example:
  
    @audio - rtprio 90       # maximum realtime priority    @audio - rtprio 90       # maximum realtime priority
    @audio - memlock unlimited  # maximum locked-in-memory address space (KB)    @audio - memlock unlimited  # maximum locked-in-memory address space (KB)
  
-Setting ''memlock'' to ''unlimited'' shouldn't be strictly necessary since most apps would work fine with lower values (such as ''500000'').\\ +Setting ''memlock'' to ''unlimited'' shouldn't be strictly necessary since most apps would work fine with lower values (such as ''500000''). However, certain applications have been reported to complain or even to crash with lower values than ''unlimited''. On the other hand, giving unlimited capability of locking memory can cause buggy applications to temporarily freeze the whole system. See http://www.linuxmusicians.com/viewtopic.php?f=10&t=2193 for more details.
-However, certain applications have been reported to complain or even to crash with lower values than ''unlimited''.\\ +
-On the other hand, giving unlimited capability of locking memory can cause buggy applications to temporarily freeze the whole system.\\ +
-See http://www.linuxmusicians.com/viewtopic.php?f=10&t=2193 for more details.+
  
 You could also allow the audio group to renice processes with the help of the ''limits.conf'' file, but since nice uses SCHED_OTHER it basically does nothing to increase the performance of a low-latency real-time audio environment that relies on SCHED_FIFO/SCHED_RR. Consult the //sched_setscheduler// manpage for more info on this subject. You could also allow the audio group to renice processes with the help of the ''limits.conf'' file, but since nice uses SCHED_OTHER it basically does nothing to increase the performance of a low-latency real-time audio environment that relies on SCHED_FIFO/SCHED_RR. Consult the //sched_setscheduler// manpage for more info on this subject.
Line 477: Line 356:
 ==== sysctl.conf ==== ==== sysctl.conf ====
  
-Suggested settings for ///etc/sysctl.conf//:+Suggested settings for ''/etc/sysctl.conf'':
  
    vm.swappiness = 10    vm.swappiness = 10
  
-This setting changes the so-called swappiness of your system, or in other words, the moment when your system starts to use its swap partition. You can check the current value with ''cat /proc/sys/vm/swappiness'', in most cases it is set to 60. This is too high, it will make your system start using swap too fast which might influence the overall performance.+This setting changes the so-called swappiness of your system, or in other words, the moment when your system starts to use its swap partition. You can check the current value with ''cat /proc/sys/vm/swappiness'', in most cases it is set to 60. For most modern systems with enough memory this is no issue. For smaller systems (embedded systems, Raspberry Pi's) this could be too high, it could make your system start using swap too fast which might influence the overall performance.
  
-There are references on the net on adjusting the ''fs.inotify.max_user_watches'' value also for enhanced performance. But it remains very unclear where these references come from and if adjusting this value actually does anything at all. The ''max_user_watches'' parameter sets the maximum number of files your system can monitor with inotify (which is part of the kernel)  for changes. Setting this parameter too low results in inotify failing. Setting it too high can make inotify needlessly consume memory. Best is to not touch the default settings as setting this parameter is unrelated to performance in an audio context.+There are references on the net on adjusting the ''fs.inotify.max_user_watches'' value also for enhanced performance. The ''max_user_watches'' parameter sets the maximum number of files your system can monitor with inotify (which is part of the kernel) for changes. Setting this parameter too low results in inotify failing. Setting it too high can make inotify needlessly consume memory. The advise of increasing this value might originate from for example DAW's or samplers that watch a lot of files and if the system runs out of watchers these DAW's or samplers fall back to polling the file system which increases disk IO which could in turn cause jitter((https://linuxmusicians.com/viewtopic.php?p=129194#p129194)). And since modern systems have mostly enough memory these days increasing this value should cause no issues.
  
 ==== audio group ==== ==== audio group ====
  
-It is generally good practice to have an 'audio' group, and add any users that should be allowed to perform audio tasks to this group. This prevents some interference from non-audio-processes with audio tasks. To verify you're in the 'audio' group, run the ''groups'' command. Remember, after adding yourself to new groups, you need to log out and back in again. Be careful when adding an 'audiogroup to your systemmost systems come with pre-configured 'audio' group, and do not warn you when you add another group with the same name, leading to much confusion.+It is generally good practice to have an ''audio'' group, and add any users that should be allowed to perform audio tasks to this group. This prevents some interference from non-audio-processes with audio tasks. To verify you're in the ''audio'' group, run the ''groups'' command. Remember, after adding yourself to new groups, it is best to log out and back in again. On systems that have an audio group you can add your user with the following command: 
 +  sudo usermod -a -audio <username>
  
-This step is verified by the [[system_configuration#Quickscan]].+Where ''<username>'' is your username. 
 + 
 +Be careful when adding an ''audio'' group to your system: most systems come with a pre-configured ''audio'' group, and do not warn you when you add another group with the same name, leading to much confusion. When using Arch Linux the above is valid too except that Arch uses a different group name, i.e. ''realtime''((https://wiki.archlinux.org/title/Realtime_process_management#Configuring_PAM)).
  
 ==== Timers ==== ==== Timers ====
  
-The configuration of hardware or software timers only matters for ALSA MIDI performance. JACK MIDI, JACK's MIDI backend drivers (like the ''alsarawmidi'' driver) and tools like a2jmidid do not care about the kernel clock frequency. When using applications that rely on ALSA MIDI (like Qtractor, SEQ24 or Rosegarden) a high resolution timer might reduce MIDI jitter and improve MIDI performance. +:!: Setting the kernel timer frequency to 1000Hz (''CONFIG_HZ_1000'') and setting ''max_user_freq'' or ''max-user-freq'' to 3072 does NOT improve the performance of your system.
- +
-=== Hardware timers === +
- +
-:!: //Using hardware timers to achieve more accurate MIDI timing is questionable. Applications that use ALSA MIDI (via either the Sequencer or the Raw MIDI Interface) may be affected by using hardware timers but it might be better to rely on a high resolution software-based timer like the ''snd-hrtimer'' kernel module.// +
- +
-Some MIDI sequencers or DAWs that rely on ALSA MIDI might benefit from being able to use hardware timers like the [[http://en.wikipedia.org/wiki/Real-time_clock|real-time clock]] (///dev/rtc//) or the [[http://en.wikipedia.org/wiki/High_Precision_Event_Timer|High Precision Event Timer]] (///dev/hpet//). When using a hardware timer make sure the 'audiogroup has read permissions on it. +
- +
-A simple ''chgrp'' might not be persistent across reboots - to make the change last, create a new ''40-timer-permissions.rules'' file in ///etc/udev/rules.d// with the following lines: +
- +
-  KERNEL=="rtc0", GROUP="audio" +
-  KERNEL=="hpet", GROUP="audio" +
- +
-It is also advisable to enable users of the audio group to use these timers at higher frequencies since the defaults are too low: +
-  $ cat /proc/sys/dev/hpet/max-user-freq  +
-  64 +
-  $ cat /sys/class/rtc/rtc0/max_user_freq  +
-  64 +
- +
-Unfortunately there's no consensus on what values to use. Most sources mention a minimal value of at least 1024 or even 2048 and a maximal setting of 8192. It might be wisest to use the values mentioned in the [[http://www.rosegardenmusic.com/wiki/low-latency_kernels|Rosegarden Wiki]] as Rosegarden is an application that relies on accurate max user freq settings. The max user freq setting for ''hpet'' can be set in ///etc/sysctl.conf// as it lives in ///proc// and the setting for ''rtc0'' can be set with an ''echo'' command at boot-time with either a start-up script or adding a line to ///etc/rc.local//+
- +
-///etc/sysctl.conf// (or something like ///etc/sysctl.d/60-max-user-freq.conf//): +
-  dev.hpet.max-user-freq=3072  +
- +
-Start-up script or ///etc/rc.local//: +
-  echo 3072 >/sys/class/rtc/rtc0/max_user_freq +
- +
-And reboot. To activate these settings immediately: +
-  sudo sysctl -p /etc/sysctl.d/60-max-user-freq.conf +
-  echo -n 3072 | sudo tee /sys/class/rtc/rtc0/max_user_freq +
-  sudo chmod 660 /dev/hpet /dev/rtc0 +
-  sudo chgrp audio /dev/hpet /dev/rtc0 +
- +
-See also: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/306458 +
- +
-This step is verified by the [[system_configuration#QuickScan]]. +
- +
-=== Software timers === +
- +
-:!: WIP+
  
 +JACK MIDI, JACK's MIDI backend drivers (like the ''alsarawmidi'' driver) and tools like a2jmidid do not care about the kernel clock frequency. When using applications that rely on ALSA MIDI (like Qtractor, SEQ24 or Rosegarden) a high resolution timer kernel module called ''snd-hrtimer'' is used that reduces MIDI jitter and improves MIDI performance. On most systems the ''snd-hrtimer'' kernel module is readily available and gets loaded when needed.
 ==== Priorities ==== ==== Priorities ====
  
Line 539: Line 383:
   $ ps axHo user,lwp,pid,rtprio,ni,command   $ ps axHo user,lwp,pid,rtprio,ni,command
  
-  $ ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i irq+  $ ps -eLo user,pid,cls,rtprio,cmd --sort rtprio
  
 Or if you have [[system_configuration#rtirq]] installed: Or if you have [[system_configuration#rtirq]] installed:
Line 552: Line 396:
 ==== rtirq ==== ==== rtirq ====
  
-rtirq is a script written by [[http://rncbc.org/|Rui Nuno Capela]], the author of QjackCtl and Qtractor amongst others. This script allows to make use of the threaded IRQs as used by real-time kernels or kernels >= 2.6.39 with the ''threadirqs'' kernel option enabled. The term threaded IRQ is quite an abstract one but what it boils down to is that every peripheral gets an IRQ and the Linux kernel splits this IRQ in different parts of which the so-called bottom-halve is of concern in the context of the rtirq script. Bottom-halves are also known in some cases as softirqs which might make this matter a bit less abstract, 'hardirqs' (the top-halves) are the IRQs assigned by the system which can't be managed from within the OS as opposed to 'softirqs' (the bottom-halves) which can be managed.+rtirq is a script written by [[http://rncbc.org/|Rui Nuno Capela]], the author of QjackCtl and Qtractor amongst others. This script allows to make use of the threaded IRQs as used by real-time kernels or kernels with the ''threadirqs'' kernel option enabled. The term threaded IRQ is quite an abstract one but what it boils down to is that every peripheral gets an IRQ and the Linux kernel splits this IRQ in different parts of which the so-called bottom-halve is of concern in the context of the rtirq script. Bottom-halves are also known in some cases as softirqs which might make this matter a bit less abstract, 'hardirqs' (the top-halves) are the IRQs assigned by the system which can't be managed from within the OS as opposed to 'softirqs' (the bottom-halves) which can be managed.
  
 [[http://www.ibm.com/developerworks/linux/library/l-tasklets/index.html|{{:wiki:softirqs.gif|}}]] [[http://www.ibm.com/developerworks/linux/library/l-tasklets/index.html|{{:wiki:softirqs.gif|}}]]
Line 563: Line 407:
   * LWN article on softirqs: http://lwn.net/Articles/520076/   * LWN article on softirqs: http://lwn.net/Articles/520076/
  
-The [[http://www.rncbc.org/jack/rtirq-20120505.tar.gz|rtirq tarball]] as available on the site of the author consists of two files, the script itself (''rtirq.sh'') and a configuration file (''rtirq.conf''). In most cases the ''rtirq.sh'' file is used as an init script (and hence stripped from the .sh extension) and ''rtirq.conf'' mostly ends up in ///etc/default/// or ///etc/sysconfig///, also stripped from its extension. Let's look at the contents of the configuration file: +The [[http://www.rncbc.org/jack/rtirq-20120505.tar.gz|rtirq tarball]] as available on the site of the author consists of two files, the script itself (''rtirq.sh'') and a configuration file (''rtirq.conf''). In most cases the ''rtirq.sh'' file is used as an init script (and hence stripped from the .sh extension) and ''rtirq.conf'' mostly ends up in ''/etc/default/'' or ''/etc/sysconfig/'', also stripped from its extension. Let's look at the contents of the configuration file: 
  
   #   #
Line 695: Line 539:
  
 And it shouldn't come up again, providing a PA free user session. And it shouldn't come up again, providing a PA free user session.
- 
-==== External links ==== 
- 
-  * Some more hints and tips on [[http://irc.esben-stien.name/mediawiki/index.php/Setting_Up_Real_Time_Operation_on_GNU/Linux_Systems|Esben-Stein]] 
-  * Some tips on the [[http://rosegardenmusic.com/wiki/low-latency_kernels|Rosegarden wiki]] 
-  * [[http://proaudio.tuxfamily.org/wiki/index.php?title=Category:Howto|here]] You can find an example for [[http://en.wikipedia.org/wiki/Gentoo_Linux|Linux/Gentoo]]. 
-  * Sound on Sound article on PCI problems: http://www.soundonsound.com/sos/dec04/articles/pcnotes.htm 
- 
- 
- 
- 
- 
- 
- 
- 
  
  
Line 716: Line 545:
 When using FireWire audio interfaces it is generally advised to use a real-time kernel. Of course this is not necessary, there are also users reporting success with generic kernels, but when you have trouble getting your system stable regarding xruns one of the first things besides installing [[system_configuration#rtirq|rtirq]] you might want to try is to [[system_configuration#the_kernel|install or compile a real-time kernel]]. When using FireWire audio interfaces it is generally advised to use a real-time kernel. Of course this is not necessary, there are also users reporting success with generic kernels, but when you have trouble getting your system stable regarding xruns one of the first things besides installing [[system_configuration#rtirq|rtirq]] you might want to try is to [[system_configuration#the_kernel|install or compile a real-time kernel]].
  
-==== Legacy FireWire stack ==== 
- 
-Make sure the raw1394 module is loaded. You can have this module loaded automatically by adding it to your ''/etc/modules'' file. Just add the following line to this file: 
-  raw1394 
- 
-Loading this module will create the ''/dev/raw1394'' node. Normal users do not have permissions to use this node but with an udev rule in ''/etc/udev/rules.d/'' you can control these permissions. Most recent distributions also install the corresponding udev rules when installing FFADO packages but if your distro doesn't do so you can create a new file ''50-raw-firewire.rules'' with the following line to allow the audio group to use this node: 
-  KERNEL=="raw1394", GROUP="audio" 
- 
-You will also need the [[http://ffado.org/|FFADO drivers]] (most distros have packages for these drivers) and set the driver for JACK to 'firewire' in either QjackCtl or on the commandline with the ''-dfirewire'' argument. 
  
 ==== JuJu FireWire stack ==== ==== JuJu FireWire stack ====
Line 735: Line 555:
  
 After setting up, configuring and tweaking your system it is still possible that it doesn't perform the way you want it to. To help analyzing why the overal performance is not as expected there are some helpful tools that might reveal the source of the bottlenecks on your system. After setting up, configuring and tweaking your system it is still possible that it doesn't perform the way you want it to. To help analyzing why the overal performance is not as expected there are some helpful tools that might reveal the source of the bottlenecks on your system.
 +
 +==== rtcqs ====
 +
 +The [[https://codeberg.org/rtcqs/rtcqs|rtcqs]] script automatically analyzes your current configuration. This script will make configuration suggestions based on your current setup and link to the relevant sections on this page for background information.
 +
 +  rtcqs - version 0.5.0
 +  
 +  Root User
 +  =========
 +  [ OK ] Not running as root.
 +  
 +  Audio Group
 +  ===========
 +  [ OK ] User music is in the audio group.
 +  
 +  CPU Frequency Scaling
 +  =====================
 +  [ OK ] The scaling governor of all CPU's is set at performance.
 +  
 +  Kernel Configuration
 +  ====================
 +  [ OK ] Valid kernel configuration found.
 +  
 +  High Resolution Timers
 +  ======================
 +  [ OK ] High resolution timers are enabled.
 +  
 +  Tickless Kernel
 +  ===============
 +  [ OK ] System is using a tickless kernel.
 +  
 +  Preempt RT
 +  ==========
 +  [ OK ] Kernel 5.17.1-rt17 is a real-time kernel.
 +  
 +  Spectre/Meltdown Mitigations
 +  ============================
 +  [ OK ] Spectre/Meltdown mitigations are disabled. Be warned that this makes your system more vulnerable to Spectre/Meltdown attacks.
 +  
 +  RT Priorities
 +  =============
 +  [ OK ] Realtime priorities can be set.
 +  
 +  Swappiness
 +  ==========
 +  [ OK ] Swappiness is set at 10.
 +  
 +  Filesystems
 +  ===========
 +  [ OK ] The following mounts can be used for audio purposes: /, /mnt/data
 +  [ WARNING ] The following mounts should be avoided for audio purposes: /run/user/1000/gvfs. See also https://wiki.linuxaudio.org/wiki/system_configuration#filesystems
 +  
 +  IRQs
 +  ====
 +  [ OK ] USB port ehci_hcd:usb1 with IRQ 16 does not share its IRQ.
 +  USB port ehci_hcd:usb2 with IRQ 23 does not share its IRQ.
 +  USB port xhci_hcd with IRQ 25 does not share its IRQ.
 +  Soundcard snd_hda_intel:card10 with IRQ 31 does not share its IRQ.
 +  
 +  Power Management
 +  ================
 +  [ OK ] Power management can be controlled from user space. This enables DAW's like Ardour and Reaper to set CPU DMA latency which could help prevent xruns.
 +
 +Discuss this script at the [[https://linuxmusicians.com/viewtopic.php?f=24&t=24000|LinuxMusicians Forum]]
  
 ==== top ==== ==== top ====
Line 740: Line 624:
 ''top'' is probably the most used tool to display system information like CPU or memory usage. It is installed by default on most distros. ''top'' is probably the most used tool to display system information like CPU or memory usage. It is installed by default on most distros.
  
-{{:wiki:top2.png|Terminal running top}}+{{:wiki:top_2023-10-15.png|Terminal running top}}
  
 With the help of ''top'' you can find out which process is using up all your CPU or memory. By pressing ''h'' you get a help screen. To sort on memory usage instead of CPU usage you can press ''F'' + ''n'' + ''Enter''. With the help of ''top'' you can find out which process is using up all your CPU or memory. By pressing ''h'' you get a help screen. To sort on memory usage instead of CPU usage you can press ''F'' + ''n'' + ''Enter''.
Line 748: Line 632:
 ''htop'' is the somewhat more sophisticated big brother of ''top''. ''htop'' is the somewhat more sophisticated big brother of ''top''.
  
-{{:wiki:htop2.png|Terminal running htop}}+{{:wiki:htop_2023-10-15.png|Terminal running htop}}
  
 ==== latencytop ==== ==== latencytop ====
Line 758: Line 642:
 ==== cyclictest ==== ==== cyclictest ====
  
-Just as ''latencytop'' measures system latencies, ''[[https://rt.wiki.kernel.org/index.php/Cyclictest|cyclictest]]'' measures kernel latencies. ''cyclictest'' has quite some options but one of the most used ways to run the command is:+Just as ''latencytop'' measures system latencies, ''[[https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start|cyclictest]]'' measures kernel latencies. ''cyclictest'' has quite some options but one of the most used ways to run the command is:
   #  cyclictest -t1 -p 80 -n -i 10000 -l 10000 -m   #  cyclictest -t1 -p 80 -n -i 10000 -l 10000 -m
 One single thread (''-t1''), priority of 80 (''-p 80''), use clock_nanosleep (''-n''), use 10000 us base interval of thread (''-i 1000''), use 1000 loops and then exit (''-l 10000''), lock current and future memory allocations (''-m''). More on clock_nanosleep can be found in its manpage (''man clock_nanosleep''). One single thread (''-t1''), priority of 80 (''-p 80''), use clock_nanosleep (''-n''), use 10000 us base interval of thread (''-i 1000''), use 1000 loops and then exit (''-l 10000''), lock current and future memory allocations (''-m''). More on clock_nanosleep can be found in its manpage (''man clock_nanosleep'').
  
 Other examples of the usage of ''cyclictest'': Other examples of the usage of ''cyclictest'':
-  * http://code.goto10.org/projects/puredyne-old/wiki/KernelAndSystemOptimization#TestingandBenchmarking +  * https://web.archive.org/web/20130727095507/http://code.goto10.org/projects/puredyne-old/wiki/KernelAndSystemOptimization#TestingandBenchmarking 
-  * https://rt.wiki.kernel.org/index.php/Cyclictest#Expected_Results+  * https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/result-examples
  
 ===== TODO ===== ===== TODO =====
-  * The ''snd-hrtimer'' module 
   * More on MIDI timing   * More on MIDI timing
-  * Harddrive tuning (does this even apply for SATA drives??) +  * Harddrive tuning 
-  * Troubleshooting tools (ffado-diag, alsa latency tool, alsa midi latency tool, jack_delay, tuna) +  * Troubleshooting tools (ffado-diag, alsa latency tool, alsa midi latency tool, jack_delay, tuna, xruncounters
 +  * Disk schedulers (BFQ, noop, mq-deadline) 
 +  * Power management 
 +  * Rewrite rtirq section or move to separate page 
 +  * Pipewire
wiki/system_configuration.1496052896.txt.gz · Last modified: 2017/05/29 12:14 by autostatic