You are allowed to go into details. What you cannot do is an un-structured brain dump full of incoherent, inaccurate information that ultimately isn’t helpful to actual users.
While you’re effectively right (assuming you use jack2 with default settings), the proper calculation for this is slightly different. The number of periods applies only to playback.
The nominal round-trip latency for Ardour/ALSA , jack1, and jack2 in sync-mode is
nominal round trip latency = (samples per period) * (1 + periods per cycle)
jack2 in async mode (the default) adds 1 cycle extra latency:
nominal round trip latency = (samples per period) * (2 + periods per cycle)
Keep in mind that this does not include systemic latencies.
If you use JACK, you can easily query them with jack_lsp -l and sum playback + capture latency. jack_lsp -l does include configured systemic latencies.
2 Likes
Let me restate some basic forum rules/meta-rules:
Do not make disparaging remarks about other forum members.
Remain focused on factual basis of the topic(s) at hand.
Do not post overly long or complex or high-information content posts. These are either typically unhelpful for a specific topic, or become outdated (yet still cross-referenced by search engines and discovered by later readers), or both.
If another forum poster has made a mistake, point out (gently) the nature of the mistake without criticizing the poster’s personal qualities. If possible, suggest an improvement rather than just the mistake.
There are no limits on what can be discussed here, but discussions must follow these rules.
See also: http://www.catb.org/~esr/faqs/smart-questions.html#idm667
And then … specifically: there is a large body of inaccurate information available online about linux kernels, realtime audio, latency and scheduling. When posting about these topics in ways that attempt to provide “answers” or “information”, it is of the utmost important that your post does not contribute to the misinformation or the confusion.
In addition, when posting about these topics, please recall that these forums are frequented by people who have been close to or even a part of the kernel development process for more than 2 decades, and that as a result, the forums’ threshold for “accurate” and “useful” information in this area is very high.
Wow, very interesting info as I work on USB only, thanks.
Does it mean that working on PCI express soundcards would be easier to get no xrun?
Any of you guys working on such a kernel in Ubuntu/Debian? I found those packages but I’m not sure it is what you meant by prempt-rt or rtirq
https://wiki.ubuntu.com/RealTime (no more support for realtime, but the post looks outdated)
https://wiki.ubuntu.com/UbuntuStudio/rtirq (there’s a link to a script)
Most likely, yes. But it really depends what the bottleneck of the system is.
The real issue might be some wireless interface or graphics-card driver or some other device that happens to share the bus. See also http://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/
Yes. The first refers to a realtime-kernel – the main benefit of which is that it allows reliably prioritize devices. The latter is a script to set this up.
Tweaking your system for pro-audio requires quite some expertise and time. This is why there are dedicated GNU/Linux distros out there. – Before diving into system-config, perhaps try eg. AVLinux (runs live from USB-key or DVD) as second opinion to see if things work nicely with the hardware you have.
Hello everyone,
I recently answered the threads topic question for me recently and want to share my results to give people a recent experience.
The overall result is that XRUNS are reduced to zero.
TL;DR: Changing JUST the used kernel (from Debain 10 stock to the Liquorix low-latency kernel) helped to get down from occasional xruns (single or a flood) on my machine with the jack settings 128 frames / 3 periods to zero xruns tested for much more than just 10 minutes while Pulseaudio is bridged to jack.
THE DETAILS (I hope their verbosity is not annoying anyone):
I read a lot about other peoples experiences and went down to tracing my stock kernel. Here is what I’ve done and what it resulted in:
Action: Wifi turned off Result: seems to not reduce xruns
Action: Swappiness from 60 to 10 Result: seems to not reduce xruns
Action: CPU governer to power Result: seems to not reduce xruns
Action: limits.conf/audio.conf Result: seems to not reduce xruns
Action: Changed priorities of apps in system monitor Result: Might reduce xruns to a half (not tested in depth)
Action: Threaded IRQ enabled Result: seems not to reduce xruns
Action: Change (test all) USB 2 ports instead of a USB 3 port Result: seems not to reduce xruns
Action: Stop all docker containers Result: seems not to reduce xruns
Action: Installed and enabled a realtime kernel Result: seems not to reduce xruns, but introduces high system load (130+ %)
Action: Tested Quartett audio interface Result: seems not to reduce xruns
Action: Used X instead of Wayland Result: seems not to reduce xruns
Action: Stopped all software in jack to test stability in general Result: seems not to reduce xruns
Action: Disabling EIST in BIOS Result: seems not to reduce xruns
Action: Using liquorix low latency kernel Result: reduces xruns (while halfing the frames per period and using pulseaudio) (tested for multiple sessions for at least an hour each)
Maybe it is interesting to know that all actions I’ve done have been reverted if there was no success. So when I say it is JUST the liquorix kernel then it is just that that has been changed. As a side note: I use Cadence and Claudia from the KxStudio repositories with standard settings (No realtime priority changed or something else - except of the frames / priod and periods of course).
TEST SETUP
- JACK runs with about 5 ms (256 frames / 3 periods)
- CPU governor performance
- CPU frequency boost enabled
- Ardour connected in jack and playing a mix
- Guitarix running
- Musescore connected in jack playng a loop
- Pulseaudio unbridged from jack
- QLC running
- aubiotrack running
- ALSA Midi bridge active
This setup was used for all tests.
Since there were no xruns using the Liquorix kernel I tried to reproduce some xruns by cutting the the frames per period in half (to 128 frames / period) AND connecting Pulseaudio to jack. This setup also succeeded and showed no xruns.
TEST DEPTH
This setup (I reduced the number of programs running in jack because I don’t need all of them at once and since I tested the Action: “Stopped all software in jack to test stability in general” and it did not reduce xruns reducing programs should not reduce xruns - CPU governor was also reverted back to power saving since this also didn’t help and saves energy) has been tested about five to ten times now for a duration of at least one hour each - some sessions were about two to three hours and there were no xruns (which were not related to rare programs actions. aubiotrack for example ALWAYS causes xruns when it is shut down - I do not take these xruns into account)
THE TEST SYSTEM
Ignore the used stock kernel below. I use the standard kernel for normal (this) work. Liquorix low-latency kernel is only used for audio sessions. (No good reason for that - I just want it that way)
Yes I run two docker containers for nextcloud.
tobias@tobias-pc:~$ inxi -Fx
System: Host: tobias-pc Kernel: 4.19.0-6-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Gnome 3.30.2
Distro: Debian GNU/Linux 10 (buster)
Machine: Type: Desktop Mobo: MSI model: Z77A-G41 (MS-7758) v: 3.0 serial: BIOS: American Megatrends v: 2.13
date: 03/07/2014
CPU: Topology: Quad Core model: Intel Core i5-3570K bits: 64 type: MCP arch: Ivy Bridge rev: 9 L2 cache: 6144 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 27201
Speed: 2290 MHz min/max: 1600/3800 MHz Core speeds (MHz): 1: 2290 2: 2495 3: 2449 4: 2672
Graphics: Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: ASUSTeK driver: nouveau v: kernel bus ID: 01:00.0
Display: wayland server: X.Org 1.20.4 driver: nouveau resolution: 1920x1080~60Hz
OpenGL: renderer: NV124 v: 4.3 Mesa 18.3.6 direct render: Yes
Audio: Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Micro-Star MSI driver: snd_hda_intel v: kernel
bus ID: 00:1b.0
Device-2: NVIDIA GM204 High Definition Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 01:00.1
Device-3: VIA VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio driver: snd_ice1724 v: kernel bus ID: 05:00.0
Device-4: Conexant Systems CX23880/1/2/3 PCI Video and Audio Decoder vendor: Hauppauge works WinTV HVR-4000-HD
driver: cx8800 v: 1.0.0 bus ID: 05:01.0
Device-5: Conexant Systems CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] vendor: Hauppauge works
driver: cx88_audio bus ID: 05:01.1
Device-6: Conexant Systems CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port]
vendor: Hauppauge works WinTV HVR-4000-HD driver: cx88-mpeg driver manager bus ID: 05:01.2
Device-7: Conexant Systems CX23880/1/2/3 PCI Video and Audio Decoder [IR Port]
vendor: Hauppauge works WinTV HVR-4000-HD driver: N/A bus ID: 05:01.4
Device-8: Focusrite-Novation type: USB driver: snd-usb-audio bus ID: 1-1.4:5
Sound Server: ALSA v: k4.19.0-6-amd64
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Micro-Star MSI driver: r8169 v: kernel
port: d000 bus ID: 03:00.0
IF: enp3s0 state: down mac: […]
Device-2: Qualcomm Atheros AR93xx Wireless Network Adapter driver: ath9k v: kernel port: c000 bus ID: 06:00.0
IF: wlp6s0 state: up mac: […]
IF-ID-1: br-37c90329cb87 state: up speed: N/A duplex: N/A mac: 02:42:70:93:01:3e
IF-ID-2: docker0 state: down mac: 02:42:fa:fd:35:01
IF-ID-3: veth864d9cd state: up speed: 10000 Mbps duplex: full mac: 36:7a:06:c3:06:00
IF-ID-4: vethacab615 state: up speed: 10000 Mbps duplex: full mac: 3e:57:55:86:bc:98
Drives: Local Storage: total: 1.03 TiB used: 789.87 GiB (75.2%)
ID-1: /dev/sda vendor: Samsung model: SSD 840 PRO Series size: 119.24 GiB
ID-2: /dev/sdb vendor: Seagate model: ST1000DM005 HD103SJ size: 931.51 GiB
PS: Tracing the kernel showed there are latencies, but I was unable to find the root cause for the latency. Since the low latency kernel works much better Iassume my system has no hardware or IRQ issues. If that is true then the latency in the stock kernel might be just caused by a normal scheduling latency. So I guess that finding the cause for the stock kernel latency would not have get me any further.
Best wishes to everyone - let me know if there are any discrepancies in my explanation.
1 Like
Hi!
Thanks for the detailed description of your test run!
I’m glad you’ve got your system working. Some of this could give other people the wrong idea.
What did you edit and what’s in them? JACK complains if it can’t run realtime threads, so your user must be given the ability to run realtime threads somewhere. Cadence shows you if your user is in the audio group under ‘System Checks’. I bet your user is in the audio group. 
It sounds like you made a mess of that. A realtime kernel is probably unnecessary for you, but it doesn’t increase CPU load like you have described. I am running a realtime kernel and my idea of low latency is 96kHz with a 32 buffer and 2 periods with JACK in synchronous mode. Not that my computer is powerful enough to do much with that but something light like Carla with Tal Noize Mak3r runs without Xruns at ~8% DSP load. The latency would have to go up to do anything more elaborate.
Did you set up GRUB and reboot and all that?
1 Like
Thanks for reviewing my post!
Some of this could give other people the wrong idea.
That is what I want to avoid!
What did you edit and what’s in them? JACK complains if it can’t run realtime threads, so your user must be given the ability to run realtime threads somewhere. Cadence shows you if your user is in the audio group under ‘System Checks’. I bet your user is in the audio group.
I raised the realtime priorities in the file and played around with higher values other than rtprio 90 to avoid xruns. That was meant by the Action: limits.conf/audio.conf.
@merlyn: Thanks for pointing this out. Definitely confusing. Is it more clear now?
Additionally (you’re right) there is something else that has to be made more clear which I thought of is “a standard procedure” (since it is more a general error rather than reducing xruns - but it also may reduce them):
I gave my user realtime priorities by adding the following lines (found here) to the audio.conf.
@audio - rtprio 90 # maximum realtime priority
@audio - memlock unlimited # maximum locked-in-memory address space (KB)
and my user was in the audio group. 
I was never happy with it since there are reasons to avoid this (Biggest problem for me: audio card is blocked for other users that are logged in - might also be an advantage). I then thought if only my user needs realtime capabilities, then only that user should get these rights and not the rights of the whole audio group. Therefore I added only my user to the limits.conf:
@tobias - rtprio 90 # maximum realtime priority
@tobias - memlock unlimited # maximum locked-in-memory address space (KB)
and removed my user from the audio group. 
Current setup: I’m not in the audio group, but I made a change to the vanilla Debian system and that is of significant importance here: I gave my user realtime capabilities.
It sounds like you made a mess of that.
My fault. I most likely did not get a higher CPU load (can’t remember it to be honest) - instead I wanted to say that I got a higher system load. Where did I gathered that information from? cpufreq (cannot provide link to GNOME extensions - not allowed) showed it. Does that makes more sense to you?
Did you set up GRUB and reboot and all that?
I did resetup GRUB (sudo update-grub) and rebootet the system and chose the RT kernel in GRUB.
Since it is fun and easy to do I might test the RT-kernel once again to make sure I did not do anything wrong here.
BTW: Pretty nice latency values. I never tried to go down that low.
Note that increasing the value in limits/audio.conf only increases the limit that you are allowed to set, so there will be no change in behavior unless you change the RT priority that your software is attempting to use. So if you had the jackd or ardour RT priority configured as 70, and increased the limit from say 80 to 90, but did not change the jackd or ardour configuration, then the audio software will still be running at RT priority 70. As the directory name implies the values in the files under the limits directory limit the maximum value you are allowed to set, they do not change the default value your software is using.
When you start jackd it will print the currently used RT priority to the console, I expect ardour would have a similar message if you open the log messages window.
You probably have to log out and log in again after making any changes to a configuration file which affects your user or group. Just adding for completeness in case someone runs across this thread.
Yes, important to know. Setting the priority limit was not the only thing I did. I raised the priority for jack set up in cadence. I played around with the priorities and checked the result with the
ps axHo user,lwp,pid,rtprio,ni,command
command to compare the priorities of the jack (and the threads of the software which jack started) threads with the other threads on the test system. I can remember that I tested values of the jack priority up to 98 or 99. 
Absolute values are irrelevant. SCHED_FIFO simply runs threads with a higher value first. It’s a simple arithmetic sort.
Have you also configured the thread priorities after enabling this? e.g with rtirq
A really cutting edge link that is. You could avoid the audio group so nobody logs in and takes over your soundcard. Do you find that happens often?
Using ALSA MIDI with ALSA sequencer requires your user to be in the audio group. It’s the sort of thing where the system will work until you try to use ALSA MIDI then it won’t work and you may be left scratching your head. That’s one reason Cadence checks. If you type
$ sudo find / -group audio
into a terminal you will see all the directories you need to be in the audio group to access.
And more of the actions you listed are like that – they’re preventative rather than aimed at fixing an Xrunning system. Disable WIFI – recommended. Swappiness – recommended. CPU governor to performance --recommended.
My values were higher than nearly every software that run on that machine. Exception was the watchdog, migration and the rtkit-daemon. So I compared the values of my software with the with the other software of the system. (Used ps axHo user,lwp,pid,rtprio,ni,command)
Since values around 70 didn’t reduce xruns I raised the values up to the highest values I was able to find on my system. (Thats dangerous - I know - It worked for that test - Currently with the low-latency kernel I reverted back to RT priority of 10 (Standard value in cadence))
Let me know if this could be done better or different.
After testing the initial version of the file rtirq.conf I edited the file as stated in the [https://wiki.linuxaudio.org/wiki/system_configuration#rtirq](http://Linux audio system configuration) according to my needs.
Can you provide a more recent link regarding that topic?
My girlfriend was unable to get sound (using another sound card? - I don’t know anymore) when she was using my computer - because I was in the audio group and was logged in in parallel. (So it happened, but we don’t use the PC in parallel currently - so not an issue anymore.
I currently use MIDI in my sessions by connecting some software with midi connections. Is that something that shouldn’t work or do you mean something else?
That’s fine - I just wanted to say that my experience is that they don’t really help me currently - maybe I’ll come back to these actions in the future. (That might be interesting to others)
I concur! A couple of weeks ago I reinstalled Linux after upgrading my 7200rpm to an Samsung Evo SSD and this is all I did to customize the antiX install aside from making cadence happy with being in an audio group etc. Compared to what I had to do to make Windows 10 happy with the same SSD re-install situation, this was heaven.
This is a good thread to share a recent experience. For years I had run KXStudio 14.04 – a distro based on Ubuntu 14.04. I had run it first on an Athlon based system, then moved the disk over to an FX-8350 system. Everything ran smoothly – no xruns or anything. This new system, I had an add-on 6GBPS SATA card in it, because the ones on the board were 3GBPS. But everything worked fine.
When FalkTX got busy on KXStudio again, I figured I’d make my own distro. I started with Kubuntu 19.10 and used a “spin your own distro” tool that kind of runs the distro in a jail while you add the repos etc. So I added the low-latency kernel, all the cool kxstudio stuff, ardour of course etc. Made myself an ISO … and installed it on a fresh disk.
I had all sorts of trouble, and I mean all sorts.
Meanwhile, I do some audio work on Windows 7, and that had never given me trouble either. But I did a fresh Windows 10 load on a drive and installed all my proprietary node-locked software and stuff.
Both the new Linux AND the new Windows (same computer for both – I have a gizmo where I just pop in the drive I need) had crackles, pops, xruns etc etc etc.
There were two problems.
The first is that I needed to set the setting in Cadence for the processor to always be at top speed. I had to do the exact same thing in Windows 10, which was tricky to find.
But I also had to remove that add-on SATA card because for some strange reason with both the latest Windows and the latest Linux kernel, it really messed up the USB bus and I use a USB sound interface.
Anyway, I thought y’all might find that interesting!
Shared IRQ seems a likely culprit. Might have been enough to move the SATA to a different slot.
Obviously not really recommended for most people, you need to know what you are doing for it to be succesful, and I am not sure that some of those ‘roll-your-own’ tools are smart enough to allow us to fix everything that is needed. Likely just going to have better luck using a distro close to it and customizing it.
Seablade
1 Like
Hi Seablade – that’s essentially what I did. I used a tool called “cubic” to make a customized kubuntu that already had all the cool Kxstudio stuff plus all the other stuff I wanted, all configured correctly, etc.
I suspect that moving the card would have been sufficient, but the SSDs could only, on the best day, move data at about 320 MB which is less than 3Gb … so the 6Gb card wasn’t buying me anything anyway. What is odd is that before the upgrades to the 5.0+ linux kernel and Windows 10, it never gave me trouble.
There is an update to my previously shared experience. (Is it really possible to get down to 0 Xruns?)
After testing more intense there are still xruns when
- WIFI state is changed (ON/OFF) - always reproducable and
- during really long sessions (I started testing for 6+ hours over night) there are few (about 100) xruns which appear at one certain point in time (midnight
- It seems the regeneration of man pages took place and was the cause for a sudden load on the system.
Another update is that I achieve similar results with the XanMod RT kernel as with the liqourix kernel. (This is positive because both reduce xruns to zero for long session duration (three hours as explained in my first comment))
That’s it. I just wanted to give feedback immediately because we are talking about zero xruns here and for my shared experience this is no longer true when testing longer.
I think I’ll come back with updates since I want to test the actions of my first post with these two kernels to get better in the long duration tests. I even need to find out more when the xruns appear and how reproducible they are.
( I cannot edit the old post - but I replied to it so everyone finding it should find my update)