There's no distinction between "user" and "kernel" that would mean kernel code gets scheduled more reliably than realtime userland threads. Or even that it necessarily has better access to the audio hardware.
If it's really really important then you'd want to move it to a custom core on the SoC of course, but that'd make a Linux port harder.
> 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.)
If it's really really important then you'd want to move it to a custom core on the SoC of course, but that'd make a Linux port harder.