LinuxMusicians

Open Source Summit 2018, Edinburgh

Maintaining a Real Time Stable Kernel - Steven Rostedt, VMware It wont be much longer before the PREEMPT_RT patch makes it into mainline. But what about supporting it for your devices? Maintaining a RT stable tree is a bit different than maintaining a normal vanilla stable tree. One must understand how the Real Time kernel works, and be able to spot changes that can cause priority inversion, or simply break the kernel. There is now an effort to have multiple people maintain various versions of Linux with the RT patch applied. This talk will present what is required to maintain a stable RT tree, such as tools that you can use. What tricks can be done with git to find properly backport patches that are RT specific. It will also cover the current tests that are performed to make sure the released RT stable kernel is fully functional.

https://www.youtube.com/watch?v=pIJ3Zv_uxn0
https://wiki.linuxfoundation.org/realti ... 2018/start

(German: https://www.heise.de/newsticker/meldung ... 02842.html)

I don't use Realtime patches anymore in years. Since Jack works in Realtime with Low latency desktop mode it's good enough for me.
5ms latency is fine.

Die Highlights von Linux 5.3: Realtime-Support im Anflug Update https://www.heise.de/ct/artikel/Die-Hig ... 70638.html \o/

(Old: Open Source Summit Europe: Realtime-Erweiterungen bald im Linux-Kernel https://www.heise.de/newsticker/meldung ... 02842.html
The Linux kernel will soon have realtime capabilities. https://elciotna18.sched.com/event/DXmm ... edt-vmware, https://www.youtube.com/watch?v=pIJ3Zv_uxn0)

==> Translate: Artificial intelligence for languages - DeepL develops artificial intelligence for understanding and translating texts. https://www.deepl.com/translator

For the majority of audio use cases, on a modern desktop machine with a recent distribution, a stock install of e.g. Ubuntu with no tweaks will give you (subjectively) at least equivalent performance to other popular OS. I've been developing audio software and plug-ins on a variety of desktop Linux machines and distros for over a decade and I've never needed to install a realtime kernel. Even less so now more of the improvements are becoming standard. The ability to customize and tweak Linux for audio is potentially an asset - but in many cases, I think the perpetuation of the idea that you need to build your own realtime this and that and you must use some custom distro (of course, you can if you need) - has proved more of a hindrance to wider adoption of Linux for audio (at least by people whose focus is making music rather than rebuilding their OS every week). All you need to do is install a recent Ubuntu LTS, download e.g. Reaper for Linux and you're good to go. (Other DAWs are available... )

I find this development pleasing.
How many real-time operating systems are (still) available worldwide?
A realtime operating system can be used optionally for your LAW (Linux^Audio), but realtime is very useful and important in many other relevant areas outside of audio.

mike@overtonedsp wrote:For the majority of audio use cases, on a modern desktop machine with a recent distribution, a stock install of e.g. Ubuntu with no tweaks will give you (subjectively) at least equivalent performance to other popular OS. I've been developing audio software and plug-ins on a variety of desktop Linux machines and distros for over a decade and I've never needed to install a realtime kernel. Even less so now more of the improvements are becoming standard. The ability to customize and tweak Linux for audio is potentially an asset - but in many cases, I think the perpetuation of the idea that you need to build your own realtime this and that and you must use some custom distro (of course, you can if you need) - has proved more of a hindrance to wider adoption of Linux for audio (at least by people whose focus is making music rather than rebuilding their OS every week). All you need to do is install a recent Ubuntu LTS, download e.g. Reaper for Linux and you're good to go. (Other DAWs are available... )

I have the impression that Windows DAWs are better in distributing the load to multiple cores. Maybe it's more complicated to do that with JACK on Linux.

bluebell wrote:I have the impression that Windows DAWs are better in distributing the load to multiple cores. Maybe it's more complicated to do that with JACK on Linux.

That can be tuned by using CPU affinity. For example:

https://access.redhat.com/documentation ... inity.html

I remember doing some research in the past and coming to the conclusion that forcefully try to parallelize DSP stuff at the OS level is not best for stability, but I cannot find any reference about this at the moment.

EDIT: As far as I remember, I think I seen posts on some forum about using CPU affinity to pretty much dedicate one core to JACK, so to be a sort of "DSP highway". I think I did tried, found that it did not improve stuff for me, and pretty much decided to roll with the defaults: those defaults know how OS work much better than me, I think.

EDIT 2: I think it must have been this: https://www.raspberrypi.org/forums/view ... p?t=221265. After looking at it again, it seems like the goal is to have certain interrupts always handled by the same core to avoid bottlenecks.

I use qjackctl with jackdmp but with the irqbalance I'm unsure if it makes sense for audio.

khz wrote:Disabling the irqbalance daemon >> https://access.redhat.com/documentation ... ss_binding

Source: viewtopic.php?p=104037#p104037

I have the impression that Windows DAWs are better in distributing the load to multiple cores. Maybe it's more complicated to do that with JACK on Linux.

I haven't noticed any major difference between e.g. Reaper on Windows or on any other platform (specifically Linux) - I mention Reaper because its the one I use most often myself.

That can be tuned by using CPU affinity. For example....

This is exactly the kind of thing I mean. I don't doubt it helps - but please, (as a thought experiment), consider that someone coming to Linux from another OS, and who sees the utility of a PC as a tool to make music, rather than as something they can endlessly take apart and reassemble in different ways for their own amusement, might assume that it is required - and at that point you / we've already lost them.

If you enjoy those tweaks, and you can convince yourself it is of quantifiable benefit, that's great. But if you use a stock Ubuntu LTS, with ALSA and a suitable DAW, it is, as I said, now subjectively at least as good as other OS as a platform for audio. It'll be just fine - and that's the message we need to get to potential users if Linux audio is going to appeal as a credible alternative. Which, right now it is ideally placed to be.

mike@overtonedsp wrote:

That can be tuned by using CPU affinity. For example....

This is exactly the kind of thing I mean. I don't doubt it helps - but please, (as a thought experiment), consider that someone coming to Linux from another OS, and who sees the utility of a PC as a tool to make music, rather than as something they can endlessly take apart and reassemble in different ways for their own amusement, might assume that it is required - and at that point you / we've already lost them.

It's like with an instrument or device. After some experience you want to get the most out of it.

It's easy to start jackd and bind it with taskset to a chosen CPU core, say 7. But on the other hand I need some means to forbid this core for all other applications. Is there a way to do that or do I have to scan all running processes and taskset them to 0-6?

You can do this statically at boot time with the isolcpus= boot parameter or dynamically using cpusets

bluebell wrote:It's easy to start jackd and bind it with taskset to a chosen CPU core, say 7. But on the other hand I need some means to forbid this core for all other applications. Is there a way to do that or do I have to scan all running processes and taskset them to 0-6?

Do you really believe you could beet the scheduler?
As long you use jackd2, you should stay away from trying that, as, jackdmp (mp stands for multi-processor, e.g. using multiple CPU's for processing the audio signal), known as jackd2, make use of more then one CPU, if it is possible, which is usually the case when you use more then one track in your DAW.

mike@overtonedsp wrote:This is exactly the kind of thing I mean. I don't doubt it helps - but please, (as a thought experiment), consider that someone coming to Linux from another OS, and who sees the utility of a PC as a tool to make music, rather than as something they can endlessly take apart and reassemble in different ways for their own amusement, might assume that it is required - and at that point you / we've already lost them.

If you enjoy those tweaks, and you can convince yourself it is of quantifiable benefit, that's great. But if you use a stock Ubuntu LTS, with ALSA and a suitable DAW, it is, as I said, now subjectively at least as good as other OS as a platform for audio. It'll be just fine - and that's the message we need to get to potential users if Linux audio is going to appeal as a credible alternative. Which, right now it is ideally placed to be.

I am not sure I follow? Please, help me understand if I am missing something.

In which way CPU affinity might be mistaken as necessary tuning from my post above? I merely stated the possibility for this to be tuned if one wants to. I also doubt that a newbie might somehow mistake something advanced as CPU affinity with some kind of necessary tuning: when I was a beginner a single look at the Arch wiki was all I needed to understand I had to make some experience somewhere else first. But I guess other people are different. Finally, this thread does not come across to me as discussing generic tuning tips for beginners. Rather, it seems to just be reporting on the activity of the Linux kernel devs, so I gess more advanced topics can take place here without beginners interpreting anything posted here as generic tips.

Maybe this was not too clear:

CrocoDuck wrote: EDIT: As far as I remember, I think I seen posts on some forum about using CPU affinity to pretty much dedicate one core to JACK, so to be a sort of "DSP highway". I think I did tried, found that it did not improve stuff for me, and pretty much decided to roll with the defaults: those defaults know how OS work much better than me, I think.

By "rolling with defaults" I essentially mean "I install my OS and do absolutely nothing about CPU affinity". As I said, I played with it, found no difference whatsoever on my system, and decided not to care. I guess I might have made it clearer: I am the skeptical one about this being useful. But you are right: only measurement and test can discern whether it helps or not. As far as I can tell, it can safely stay at the bottom end of "stuff to try" barrel.

Which brings me to:

tramp wrote:Do you really believe you could beet the scheduler?

This is what I mean by "those defaults know how OS work much better than me, I think.".

tramp wrote:

bluebell wrote:It's easy to start jackd and bind it with taskset to a chosen CPU core, say 7. But on the other hand I need some means to forbid this core for all other applications. Is there a way to do that or do I have to scan all running processes and taskset them to 0-6?

Do you really believe you could beet the scheduler?
As long you use jackd2, you should stay away from trying that, as, jackdmp (mp stands for multi-processor, e.g. using multiple CPU's for processing the audio signal), known as jackd2, make use of more then one CPU, if it is possible, which is usually the case when you use more then one track in your DAW.

I use jack2. As I understand jack2 can only use more than one CPU if there are multiple jack clients. Qtractor acts as one client only if I remember correctly what Rui explained some time ago.

Are there DAWs behaving like multiple jack clients, maybe one client per track?

bluebell wrote: Qtractor acts as one client only if I remember correctly what Rui explained some time ago.

Are there DAWs behaving like multiple jack clients, maybe one client per track?

Maybe that is one of the reasons why Rui stated that Qtractor is not a DAW? Ardour does it, for example.