Thanks for bringing this up, I wasn't aware that there were prepackaged "high performance" kernels available. I briefly tried the xanmod-rt kernel on a laptop that has given me a lot of xrun grief. This was kubuntu 20.04 and the first kernel I tried was xanmod-rt, installation was very easy so I can recommend people trying it out, switching between kernels during boot is usually simple. Anyway, this kernel did not complete the boot sequence so .. not that great. Then I tried the xanmod-rt-edge (or something along those lines). It does boot but sadly does very little to improve the xrun situation. This is anecdotal and I'm inclined to think there is something seriously wrong with this laptop which makes it inherently rt-unfriendly. But I will do more tests as I'm basically a bit disappointed with the realtime-ness I've been able to achieve on various hardware lately. I really thought it would be easier to achieve reliable performance at, say 44100 and 128 frame buffers. It's been a long time since I tried any competing operating systems so I might be wrong and assume too much, but I'm pretty sure OS X can do this in a quite stable way. Regards, Robert Den tis 2 juni 2020 kl 12:48 skrev Roger <gurusonic(a)gmail.com>om>: https://www.phoronix.com/scan.php?page=article&item=xanmod-2020-kernel _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-user

On Thu, Jun 4, 2020 at 3:26 AM <nik(a)parkellipsen.de> wrote: desktop This is wrong. The behavior of a "normal", "low latency" and "preempt-RT" kernel are all different, and for realtime audio work, the correct behavior is only going to happen with a "preempt-RT" kernel. However ... The behavior of the normal and "low latency" kernels have changed over the years too, and on *some* systems (from a hardware perspective), they will function similarly enough to a "preempt-RT" kernel that a realtime audio workflow will be just fine. In addition, the "behavior" gap between a "preempt-RT" kernel and a normal kernel will be less and less apparent as the latency settings (buffer/period size) become more relaxed (i.e. grow larger). How do you know which systems this is true for? You just have to try it. It is a complicated mixture of many different aspects of the hardware. There's an overview of the kinds of things that can contribute to the need for a "preempt-RT" kernel here: https://manual.ardour.org/setting-up-your-system/the-right-computer-system-…

This is wrong. The behavior of a "normal", "low latency" and "preempt-RT" kernel are all different, and for realtime audio work, the correct behavior is only going to happen with a "preempt-RT" kernel. However ... The behavior of the normal and "low latency" kernels have changed over the years too, and on *some* systems (from a hardware perspective), they will function similarly enough to a "preempt-RT" kernel that a realtime audio workflow will be just fine. In addition, the "behavior" gap between a "preempt-RT" kernel and a normal kernel will be less and less apparent as the latency settings (buffer/period size) become more relaxed (i.e. grow larger). How do you know which systems this is true for? You just have to try it. It is a complicated mixture of many different aspects of the hardware. There's an overview of the kinds of things that can contribute to the need for a "preempt-RT" kernel here: https://manual.ardour.org/setting-up-your-system/the-right-computer-system-…

Do you mind sharing a bit more what settings and toolchain this includes? kernel? distro? Jack? what buffersettings?

On 6/7/20 1:48 PM, rosea.grammostola wrote: Fwiw, I did my best to optimize a thinkpad t420 laptop for linuxaudio using the realtime script from the wiki mostly and the information in the Ardour docs. > At least I can run Zynaddsubfx with 0.726 msec latency now without > xruns using a cheap Behringer usb device. ;)

On 6/7/20 7:31 PM, rosea.grammostola wrote: Me again :p Disabled the networking (devices). I can play Zynaddsubfx via usb midi keyboard with 0.7626 msec latency, without a single xrun now (testing it the last +- 30 minuts)... With this cheap usb device. Quite shocking... to me at least.

On Sun, 7 Jun 2020, rosea.grammostola wrote: It was my understanding that the USB bus has a hard limit of 1ms.

On 6/7/20 9:24 PM, Len Ovens wrote: When I push the limits even further, JACK won't start and I find no way to get it running again with this usb card, even with less strict setting. I can make it work after reboot. Maybe it has something to do with it? _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-user

Hi all, Just wanted to report some results and conclusions I've drawn so far with my renewed interest in getting a more reliable low latency configuration, so Internet can archive it... My testing mainly focused on running with 44100 and 64 and 128 frame buffers. Though a cool feat to run jack at 16 frames, that's not so important to me. My use case is mainly recording audio and midi with real time listening. I've installed the linux-xanmod-rt-edge kernel on the same type of laptop that rosea grammostola mentioned, Thinkpad T420, running kubuntu 18.04. I removed the gui login from X with sudo systemctl set-default multi-user.target and instead use startx as I think this shaves off some overhead. Running governor performance, this kernel (or atleast cpufreq tools) lists userspace (with a set frequency) as a possible governor, as I have used this in the past and found it superior I tried to configure it again but it doesn't seem to bite... the setting is done but the frequency still changes freely so I reverted to performance governor. I made a little midi test file that I planned to use with Surge and Dexed synths. First I used the built in soundcard but when going for 64 frames it really struggled to work. jack can start in this configuration but neither ardour or muse could use it reliably, muse only output a never ending stream of xruns, ardour actually made some sound but it was mostly noise. With Ardour going directly with alsa it didn't even pass the configuration step. Being somewhat miffed by this outcome I eventually remembered to try with my firewire soundcard and the behaviour was much better! I'm not really sure why I expected the internal soundcard to work well... in retrospect it is hardly part of it's expected use. With the firewire interface (Presonus Firestudio project) I could successfully use the test song I put together in MusE with both Surge and Dexed without any xruns during playback. I kept adding a few synths and plugins and it was pretty stable up to maybe 50% dsp load (as reported in muse, I believe this metric comes from jack though), more load than that and xruns were starting to occur a bit too often. I didn't A/B between Ardour and MusE in this configuration yet so I can't say if the xruns stem from muse or another part of the system. I do however have the distinct feeling that the realtimeness of this configuration still leaves a bit before it is comparable to say a similar Macbook running OS X. .. (I really should get my hands on one for testing..) and I would really like to understand where the bottlenecks are, especially if they are fixable.. In theory (as I understand it), as the dsp execution is done in a realtime thread, it should be able to reach close to a 100% utilization before xruns need to occur. I guess there a few hardcore things I neglected this far, disabling network, upping the priorty of irqs etc. Would be nice if these kinds of things were not necessary though.. Any other ideas of what I neglected are welcome. Regards, Robert Den sön 7 juni 2020 kl 22:40 skrev rosea.grammostola <rosea.grammostola(a)gmail.com>om>: _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-user

Disabled the networking (devices). I can play Zynaddsubfx via usb midi keyboard with 0.7626 msec latency, without a single xrun now (testing it the last +- 30 minuts)... With this cheap usb device. Quite shocking... to me at least. >

Alright, as someone (Len I think) pointed out, it should not be possible over usb. It's always good to learn more anyway. What procedure did you use to disable network devices btw? I should try disabling wireless at least. I see systemctl has several network manager services on this computer.

Hmm I never felt any advantage using RT kernels, either, at least in the recent years, so I wonder if they still have any advantage in 2020 ? And that's not a rhetorical question, I really wonder what contemporary use cases for RT kernels in the audio world are. I feel like these kernel-tuning approaches date back to times when desktop responsiveness etc. were much more serious issues. Might be wrong here, of course. Best, n Robert Jonsson wrote on 04.06.2020 10:04 (GMT +02:00): _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-user

On 04/06/2020 11:25, nik(a)parkellipsen.de wrote: I concur that with some applications a RT kernel can be beneficial, think of running soft-synths or samplers at very low latencies (with buffer sizes below 128 samples) or for use with dedicated devices like MOD Duo, Zynthian and that TC Electronics device that passed here a couple of days ago. When using a DAW the benefits of using a RT kernel are less clear. Out of curiosity I did some small tests with a 20 track Mixbus32C session using ALSA at 128 samples buffer size, 3 periods and 48kHz sample rate and with both a home-rolled 5.6.14-rt7 and a stock Ubuntu 5.3.0-lowlatency kernels the number of xruns stays below 5. Session is about 3 minutes long and consists of a DrumGizmo Crocell kit and some guitars running Guitarix, all real-time (so no bounced tracks). This is on a somewhat older notebook with one of the first Intel i7 iterations, a tweaked Ubuntu 18.04 (no hyper-threading, no Bluetooth, no Wifi) and a decent USB sound card sitting on its own USB bus. Thought I'd share it, maybe it helps people to decide if they should try a RT kernel or not. For all a RT kernel is not a panacea that miraculously solves your xrun problems, those problems could lie elsewhere as already pointed out by others. Additionally to the Ardour manual link I'd like to point to https://wiki.linuxaudio.org/wiki/system_configuration. Even though it's a somewhat older article it still contains valuable information that could help pinpointing the cause of xruns. Best, Jeremy

Hello Roger, On 06/06/2020 13:59, Roger wrote: I don't think that's really necessary anymore as almost everything in Linux audio land that needs a high resolution timer uses the snd-hrtimer kernel module these days which doesn't rely on this kernel setting. Correct me if I'm wrong though, timers have always been a blind spot in my understanding of how the kernel works with regard to real-time audio. Best, Jeremy

Hello Tim, I checked sound/core/hrtimer.c of a current linux kernel source and I don't see any limits of 1000 or 1024. And when I check on my system with `cat /proc/asound/timers` I see the resolution of the system timer is 1000 µs, so 1 ms (which I think equals the 1000 HZ kernel setting I use) while the HR timer has a resolution of 0.001 µs, so 1 ns. If I search for .resolution in /proc/timer_list I see that same value, so 1 ns. So my guess is that snd-hrtimer goes way beyond 1000 HZ and doesn't seem to have a hard-coded limit of itself. Best, Jeremy