The things we do for a few milliseconds of latency...
Like today, patching the Linux kernel to create a memory-mapped buffer that both the kernel and a JACK client can use at the same time.
(the previous/mainline code was using an alsa virtual device to expose the audio data)
Reduced latency of the "task" by around 20ms ✨
Now just need to deal with ARM memory barriers and other details to ensure a good sync, I think...
@falktx This feels like some kind of wizardry to a mere Linux audio user like me. I'm very glad people like you do this sort of thing. Thanks.
@falktx 20ms is a lot in my (live) audio world. What total round trip latency are you looking to achieve after the change?
@texec less than 10ms was the target.
with this change the device-induced latency is around 5.5ms, then any extra for block-size buffers (so e.g. 2.6ms for 128 frames / 48kHz)
For the curious ones, kernel diff https://github.com/Darkglass-Electronics/radxa-kernel/commit/1c99fb0a7788811a4eb212c3c0bdcb64dc9d955f
and user-space side https://github.com/falkTX/audio-bridge/blob/main/src/audio-device-impl-linux-mmap.cpp