The linux DAW thread

[audiojunkie]

It’s finally happening!! 20 years in the making!!

This is big big BIG news!!!

PREEMPT_RT Might Be Ready To Finally Land In Linux 5.20

https://www.phoronix.com/news/520-Maybe ... PREEMPT_RT

After years in the works, the "PREEMPT_RT" support for building a real-time Linux kernel might finally be mainlined for the upcoming Linux 5.20 cycle if the last few remaining bits are reviewed/signed-off on in time for next week's merge window.

The Linux real-time patch series has been getting smaller with time and quite close to crossing the finish line with just around 50 patches to be merged. This allows for building a real-time / fully preemptible kernel off the mainline code for embedded Linux systems.

For years there had been talk of PREEMPT_RT coming "soon" to mainline but ultimately didn't pan out. The Linux RT developers were held up by funding.

The change this year though was Intel acquiring Linutronix as the Linux consulting firm heavily involved in the PREEMPT_RT patches.

Now today the word is that PREEMPT_RT could be ready for Linux 5.20 if the last two blockers are sorted out this week. Sebastian Andrzej Siewior of Linutronix wrote on the kernel mailing list:
a polite ping for the series. This is one of two road blocks to get RT enabled in v5.20. I don't want to add any pressure just point out that I can't sit still for days since the end is near

Sebastian

That patch series are two signal/ptrace related patches needed for the PREEMPT_RT series. We'll see over the next two weeks during the Linux 5.20 merge window if the PREEMPT_RT patches are all aligned to finally be merged and there are no last minute issues or objections from Linus Torvalds or other key participants.

[Kott]

why it's so important?

[audiojunkie]

With this and the preempt_dynamic kernel parameter, most musicians won’t won’t have to struggle with compiling a custom kernel. It’s another step in making Linux more accessible for ordinary users.

[Kott]

With this and the preempt_dynamic kernel parameter, most musicians won’t won’t have to struggle with compiling a custom kernel. It’s another step in making Linux more accessible for ordinary users.

why to compile a custom kernel, what's wrong with default?

[audiojunkie]

Nothing is “wrong” with the default. It’s just that there was question as to whether the project to mainline the realtime patches was ever going to be finished or not. Now, completion seems certain. To me, that is big news and cause to celebrate.

But, I think you already knew all this, and you just disagree with my opinion that it is important news

[Kott]

yes, I still wonder about RT kernel importance for the audio

[glokraw]

Current stock kernels allow a lot of music productivity, but for users needing maximum stabilty and increased performance from older computers, Rt will be a nice help. It always has been. Most of the world won't be rushing to buy the latest fire-breathing cpu's, so Rt might mean an old decrepid computer
by kvr standards, might be able to go from three to 7 layers in yoshimi, add a couple extra rakarrack panels, or load a Kontakt instance for the first time
yada yada yada

It also will help the new linux user on whatever gear they use, to have a more positive first few experiences, without diving as deeply into the current array of config files. Cup half full, and rising

[glokraw]

some old definitions etc

https://elinux.org/images/d/de/Real_Tim ... arison.pdf

[Kott]

...
so Rt might mean an old decrepid computer
by kvr standards, might be able to go from three to 7 layers in yoshimi, add a couple extra rakarrack panels, or load a Kontakt instance for the first time
...

Are you sure with that? It seems for me that many people believe that RT means "more performance" while it's absolutely not.

[audiojunkie]

...
so Rt might mean an old decrepid computer
by kvr standards, might be able to go from three to 7 layers in yoshimi, add a couple extra rakarrack panels, or load a Kontakt instance for the first time
...

Are you sure with that? It seems for me that many people believe that RT means "more performance" while it's absolutely not.

Performance? No, absolutely not. That's a big misconception. You "LOSE" performance when running a real time kernel. However, what you gain, is what music producers really want--much lower audio latencies and tighter timing all around.

I apologize for being defensive. I believed you knew that already, and just disagreed with me that this is good news. I was waiting for you to argue with me and I defensively was trying to avoid it.

Don't you run the OBS GeekOS repository? I was sure it was you. That's why I figured you knew all of this. Maybe I was thinking of someone else.

Edit: Yes, it does indeed appear that I was thinking of someone else. Basslint on the LinuxMusicians forum is who runs GeekOS. But I do see that you've talked to him in the past:

https://linuxmusicians.com/viewtopic.ph ... 3&start=30

So, again, I apologize for thinking you were someone else and being defensive.

[Kott]

However, what you gain, is what music producers really want--much lower audio latencies and tighter timing all around.

If you get different latencies in audio with RT and non-RT kernel, then it means your system is overloaded or working incorrect.
Real time means the time-guaranteed answer from the system (kernel) to the process (thread), so the cycles in the process won't stay interrupted for unknown time. If it's impossible to run the process within defined period, then it should get an answer that no resources are available. That's my very simple interpretation.

Don't you run the OBS GeekOS repository?

Yes, I'm a maintainer (one of few) of this repo.

[Kott]

I apologize for being defensive. I believed you knew that already, and just disagreed with me that this is good news. I was waiting for you to argue with me and I defensively was trying to avoid it.

Nothing to apologize)
I'm just strangling the rapture, because high expectations causes big disappointments.

[audiojunkie]

However, what you gain, is what music producers really want--much lower audio latencies and tighter timing all around.

If you get different latencies in audio with RT and non-RT kernel, then it means your system is overloaded or working incorrect.
Real time means the time-guaranteed answer from the system (kernel) to the process (thread), so the cycles in the process won't stay interrupted for unknown time. If it's impossible to run the process within defined period, then it should get an answer that no resources are available. That's my very simple interpretation.

A vanilla generic kernel has incorporated more and more of the real time patches over the years--version by version. It is because of these incorporations of patches over the years (along with putting oneself into the real time group and other tunings) that low latencies can be achieved as well as they are. If we were to go back a few years to a kernel that didn't have any of Ingo Molnar's real time patches incorporated, even if one placed themselves within the real time group, they wouldn't achieve the low latencies that are able to be reached today without compiling specifically for low latency, or even real time usage. Personally, I feel that a low latency kernel is sufficient, and compiling a kernel specifically for real time hasn't been necessary for quite a while. At any rate, I'm sure that Ingo feels a huge relief that his life's work is finally going to be accomplished. Things were unsure for quite a while.

[audiojunkie]

I apologize for being defensive. I believed you knew that already, and just disagreed with me that this is good news. I was waiting for you to argue with me and I defensively was trying to avoid it.

Nothing to apologize)
I'm just strangling the rapture, because high expectations causes big disappointments.

Yes, I agree. As much as I think it's great news that all of Ingo Molnar's patches are going to be mainlined and there is no worry of the project dying before being completed, the news can be misinterpreted by those who don't know linux well.

In another thread, I was raving about my experiences with Fedora. Everything has been working flawlessly for me (But then again, I've been using Linux for years, and I'm still learning something new every day). Another user wiped out his setup and installed Fedora. To his dismay, he did not achieve the results I raved about. He got frustrated, and in the end, went back to Windows.

I feel really bad that because someone read about my experiences, tried and failed, and has moved back to Windows. I didn't lie--everything that I raved about was true, but my comments were what gave him the high expectations and in the end caused his big disappointment. I realize that I need to stress much more heavily that while things are getting easier and better and better, the learning curve is very real. And, without knowing Linux, what may be easy for one may be a struggle for another.

[Kott]

He just had to install openSUSE

PS I'm still using no pipewire on my machine, alsa+jack+pulseaudio works for me perfectly, so I cannot say any useful about that case.