> There's no distinction between "user" and "kernel" that would mean kernel code gets scheduled more reliably than realtime userland threads. The distinction i

> There's no distinction between "user" and "kernel" that would mean kernel code gets scheduled more reliably than realtime userland threads. The distinction is that the kernel submits buffers to hardware, so it can do safety-related checks synchronously. If it doesn’t get scheduled, nothing plays, and the tweeters don’t burn out. This can be done in userspace, too. Something in the kernel (ALSA? A driver?) could call into what would be, in effect, a userspace audio codec driver. That userspace driver would do its safety checks and then send the buffer off to the codec for playback. It’s a bit sad that x86’s abysmal context switching performance has helped nerf microkernel and userspace driver development for years. Fortunately we’re talking about ARM64 here. (On modern systems, the tens of thousands of cycles x86 spends doing nothing useful when context switching or handling interrupts don’t matter as much as they might have when CPUs we’re slower.)