Linux 6.3 printk Changes Prepare For Threaded/Atomic Consoles

[Quackdoc]

It's really easy to set the buffer to be really small and be amazed at hearing your voice back.

Unfortunately, for serious audio work, this is not enough. If you'd ran your audio pipeline for longer, let's say a few hours, you'd log XRUNs. I'm not saying you'd notice them, but log them.

PREEMPT_RT is a requisite for pro audio, where no XRUN is ever acceptable.

Without having to involve yourself with audio, you can still see the difference fairly quickly, by using the tools in rt-test.

Particularly, you can leave `cyclictest -S --policy fifo` for a while. The column that matters the most is the Max one, as that's the maximum latency (in microseconds) from the intended time to the time the process actually got the CPU, in SCHED_FIFO, which is the realtime POSIX way of saying "if this process is runnable, drop what you're doing and run this process until it yields the CPU itself".

You'll observe that, without PREEMPT_RT, you'll get numbers that are far beyond what's acceptable in a manner of minutes. With just a day or two, I have seen values that go over the duration of a video frame at 60Hz. Nevermind audio, this is very bad behavior, not adequate for human interaction, such as use in a desktop/laptop/workstation/phone/tablet system.

With PREEMPT_RT, you'll see the realtime work actually does a great job in providing soft realtime, and the max column will keep sane even after weeks running. In most of my CPUs, it'll stay at 2 digits or <100us, a very workable upper bound.

I'll give this a try, but at the very least, it would depend on the definition of pro audio, I know at least two people working with pipewire doing relatively serious audio work that don't have issues.

[sinepgib]

It's really easy to set the buffer to be really small and be amazed at hearing your voice back.

Unfortunately, for serious audio work, this is not enough. If you'd ran your audio pipeline for longer, let's say a few hours, you'd log XRUNs. I'm not saying you'd notice them, but log them.

PREEMPT_RT is a requisite for pro audio, where no XRUN is ever acceptable.

Without having to involve yourself with audio, you can still see the difference fairly quickly, by using the tools in rt-test.

Particularly, you can leave `cyclictest -S --policy fifo` for a while. The column that matters the most is the Max one, as that's the maximum latency (in microseconds) from the intended time to the time the process actually got the CPU, in SCHED_FIFO, which is the realtime POSIX way of saying "if this process is runnable, drop what you're doing and run this process until it yields the CPU itself".

You'll observe that, without PREEMPT_RT, you'll get numbers that are far beyond what's acceptable in a manner of minutes. With just a day or two, I have seen values that go over the duration of a video frame at 60Hz. Nevermind audio, this is very bad behavior, not adequate for human interaction, such as use in a desktop/laptop/workstation/phone/tablet system.

With PREEMPT_RT, you'll see the realtime work actually does a great job in providing soft realtime, and the max column will keep sane even after weeks running. In most of my CPUs, it'll stay at 2 digits or <100us, a very workable upper bound.

But that's the point, nobody denies you may need rt for real audio work. I don't do that, so I won't pretend to know. Just most users don't do serious audio work and you default for the common case, not the specialized case. Video conferencing is common, but it works without rt.