It's a bit weird but I have such a nostalgic connection to this very specific BeOS ability.
As a teenager I had heard about BeOS and I tried it out. I must have gotten it from a magazine's CD.
And by mistake, clicking around, I opened all of my mp3 collection's files at the same time. Each of the mp3s opened in their own little player window - and they all started playing at the same time, without the UI starting to lag at all.
It gave me an appreciation of what a computer can do
Almost all of the original PREEMPT_RT patchset are mainlined now, but the features are not (all) enabled by default. Low latency will always present a tradeoff with bandwidth, and Linux is used for so many different purposes that one is not clearly more important than the other.
For more than 10 years, Linux with the PREEMPT_RT patch has been capable of more-or-less hard real time, with latencies in the 10's of usecs range. That can be thwarted, however, by a variety of hardware features (SMI being the worst offender, plus devices that hog the PCI bus for too long), so you are not guaranteed this performance just by running that kernel.
For hard realtime, you need guarantees. Linux is too complex and cannot possibly offer them; this is the territory of formal proof, with complexity growing exponentially with code size.
Even with the "guarantees" offered by e.g. seL4, you still need cooperating hardware. SMIs on most mobos cannot be masked, and can take an eternity to be handled by the BIOS.
Fortunately, for realtime audio, you don't need hard realtime unless you're very close to overloading the CPUs. Soft realtime (i.e. 99% of all interrupts handled within N usecs, 100% handled with N*2) is good enough.
Right. Also for hard realtime with 100% deadline guarantees (absence of soft and programming errors assumed, for a second) you would choose an appropriate CPU like the ARM Cortex-R series. You'd also take care of the peripherals, i.e. choose 801.2AS or even Flexray.
One of the problems is that the Linux RT kernel doesn’t stop you from using/writing devices/drivers that break those guarantees systemwide, as I understand it.
A kernel alone on a random hardware platform can't, but a kernel and a hardware core that watchdogs and flips the bird at a rt-violating driver+device, sure (I've toyed with VxWorks on devices that work this way).
Usually when you're entering that realm of such requirements, you're rarely talking about off-the-shelf devices.
One that has no such drivers? Which would then imply limited hardware support as the price for the guarantee, which is a trade-off a general purpose kernel like Linux isn't going to make.
If anyone wants to try the as-much-rt-as-possible build in a nice ready package, there's the Xanmod project https://xanmod.org/ which offers it precompiled with a few other tweaks. It's aimed at gamer crowd, but I had a really good experience using it with music processing.
The default xanmod kernel is still not using the PREEMPT_RT features. They do note that "Real-time Linux kernel (PREEMPT_RT) build available [5.10-rt]." and that's how you get "as much RT as possible". The features in the normal version of their kernel will improve the user experience of latency, but will not address "realtime" in the way that PREEMPT_RT does.
Is it possible to make a BSD kernel real-time. (No, IIRC.) I notice Elk uses Xenomai. NetBSD has a utility called schedctl that purports to control the scheduling of threads and processes. An example in the manpage describes running top(1) with "real-time priority". https://man/netbsd.org/schedctl.8
The ability to compile a (close to) real-time kernel seems to be one difference between Linux and BSD not often discussed.
The approach of making general-purpose OS kernels realtime seems like hard work to me. Surely what we want is a realtime microkernel, on which the conventional operating system can run as a (large!) task. As long as there is a way for processes running under the kernel to start realtime tasks directly on the microkernel, you can support all your realtime use cases, without having to make the whole operating realtime.
'real time' generally means latency guarantees and trading some throughput for consistent low latency for interrupts and scheduling. So faster in some dimensions and slower in others.
The Arch Linux wiki has some description of their real time patches:
Arch wiki is an amazing source of practical information. It's like graybeard forums but distilled into a readable text. My last laptop ran Mint distro; whenever I searched around for HW issues it was always their wiki, fully stocked with useful info and steps how to fix stuff.
I'm referring to the usenet, mailing lists, various issue trackers and distro-specific forums were knowledgeable people diagnose and solve problems for others. The arch wiki has some of same diagnostics/troubleshooting content in more approachable format and kept up to date. Quite a few times it pointed me in right direction even if I don't use Arch.
Often it's explicitly not faster— you intentionally do work in a more interruptible/resumable/chunked way even if it's less efficient to do it that way than to just block the system and do it all in one shot.
These kinds of tradeoffs don't make sense for a lot of common Linux workloads, which is why it isn't the default.
Yes, and: in return you get documented guarantees about how much time certain operations are allowed to take. As opposed to “We work hard to make it fast most of the time. But, no promises because sometimes stuff happens.”
Real time offers predictability. In some contexts being certain of a 3ms latency is better than going randomly from 1 to 4ms which could make the code faster on the average but with less predictable timings.
Here’s a download link if anybody is interested:
https://github.com/elk-audio/elk-pi/releases