61–70 of 165 posts
It’s a Linux distribution with real-time kernel. Here’s a download link if anybody is interested: https://github.com/elk-audio/elk-pi/releases
what is a real time kernel vs a normal kernel? just "faster"?
The Arch Linux wiki has some description of their real time patches:
> 1ms round-trip Ooh, a rare latency claim that actually specifies which type of latency they mean! One millisecond round-trip latency, if true in practice, is quite impressive. I'm going to continue reading now... :)
I’ve never understood the latency requirement for professional gear, are you able to articulate why there’s a need for lower latency than average consumer gear?
At 10ms (and possibly less), you will start to notice the lag and it will affect your performance.
https://www.soundonsound.com/sound-advice/q-how-much-latency...
Earlier quoted context omitted.
I’ve never understood the latency requirement for professional gear, are you able to articulate why there’s a need for lower latency than average consumer gear?
It only takes a small amount of latency (5 ms or so) to noticeably impact performances by musicians. Latency is also an issue when you want to monitor a live signal along with other recorded audio, like in a DAW. It is not as big a deal with a playback only device.
Jitter is killer though - if the latency is randomly changing it's really annoying.
Reminds me a lot of the Bela project [1]. The idea is that they expose the raw audio device interrupt handler so applications can do DSP processing without the kernel being involved at all. Wonder if this is doing something similar? [1] https://bela.io/
Bela does not expose the audio device interrupt to applications. Your code runs in the Xenomai RT kernel, which functions somewhat like a hypervisor. That means that your RT code doesn't run as part of Linux at all. It also means that you need to use Xenomai-specific techniques if you need to communicate with regular Linux application code. You'd get more or less the same thing by writing a kernel module for Linux, w…
Earlier quoted context omitted.
So the real time kernel patches have been mainlined? How comprehensive are the real time features of Linux now?
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…
It’s a Linux distribution with real-time kernel. Here’s a download link if anybody is interested: https://github.com/elk-audio/elk-pi/releases
what is a real time kernel vs a normal kernel? just "faster"?
These kinds of tradeoffs don't make sense for a lot of common Linux workloads, which is why it isn't the default.
Earlier quoted context omitted.
It only takes a small amount of latency (5 ms or so) to noticeably impact performances by musicians. Latency is also an issue when you want to monitor a live signal along with other recorded audio, like in a DAW. It is not as big a deal with a playback only device.
rule of thumb is that sound travels roughly 1ft per ms, so 5ms is the same as standing 5 extra feet from the speaker. Most musicians don't have much trouble up to around 10-20ms. Jitter is killer though - if the latency is randomly changing it's really annoying.
Or is this just meant as a visualization of latency in these scenarios versus what it would be like with musicians playing x ft apart from each other in a room?
Earlier quoted context omitted.
That's necessarily going to be aspirational in at least some respects, though—it's limited by the hardware.
I wonder if there's a way for computers to self-measure round trip. Even if you have to plug an aux cord between the speaker + mic jacks.
Earlier quoted context omitted.
what is a real time kernel vs a normal kernel? just "faster"?
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.
Earlier quoted context omitted.
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…
>more-or-less hard real time Also known as soft realtime. 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. Look at seL4 for hard realtime.
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.