3 ms·

> CoreAudio is actually pretty good. I wasn't arguing that, I was saying that "millisecond latency" involves frames smaller than (samplerate / 1000) samples, c

> CoreAudio is actually pretty good. I wasn't arguing that, I was saying that "millisecond latency" involves frames smaller than (samplerate / 1000) samples, completely ignoring overhead. > Without the linux-rt patchset, jack pipelines do overrun even when running jack at 10ms. Linux has quite the latency spikes. Are we talking about sub-10ms latency? Sure, that's a different matter, and Linux's default schedulers could stand to improve support for mixed-realtime.

snvzz 8y ago
>Are we talking about sub-10ms latency? Yes. Even for the audio case, having to run jack at 10ms is already a lot, particularly since Linux is not the only source of latency. >Sure, that's a different matter, and Linux's default schedulers could stand to improve support for mixed-realtime. Even SCHED_FIFO (where preemption is immediate, and cpu isn't released until the high priority program yields it itself) suffers from latency spikes; it is not a scheduler issue but an overall Linux design issue. cyclictest from rt-tests will easily highlight that. Try leaving cyclictest --smp -p98 -m on the background. After a while, you'll notice the entirely unacceptable max latency readings. All the test does is set an alarm so that the task becomes runnable (which means it should run immediately due to SCHED_FIFO) and check the difference between the alarm and the current time. Mainline kernel is effectively unusable for anything that requires low latencies such as audio work, as it spends too much time running non-preemptable code in supervisor mode. Linux-rt improves this situation radically, but the monolithic design simply isn't suitable for this; microkernel multiserver systems are a much better fit. Incidentally, refer to seL4 for a system that has a guarantee in the form of a formal proof of worst case execution time.

snvzz 8y ago

>Are we talking about sub-10ms latency? Yes. Even for the audio case, having to run jack at 10ms is already a lot, particularly since Linux is not the only source of latency. >Sure, that's a different matter, and Linux's default schedulers could stand to improve support for mixed-realtime. Even SCHED_FIFO (where preemption is immediate, and cpu isn't released until the high priority program yields it itself) suffers from latency spikes; it is not a scheduler issue but an overall Linux design issue. cyclictest from rt-tests will easily highlight that. Try leaving cyclictest --smp -p98 -m on the background. After a while, you'll notice the entirely unacceptable max latency readings. All the test does is set an alarm so that the task becomes runnable (which means it should run immediately due to SCHED_FIFO) and check the difference between the alarm and the current time. Mainline kernel is effectively unusable for anything that requires low latencies such as audio work, as it spends too much time running non-preemptable code in supervisor mode. Linux-rt improves this situation radically, but the monolithic design simply isn't suitable for this; microkernel multiserver systems are a much better fit. Incidentally, refer to seL4 for a system that has a guarantee in the form of a formal proof of worst case execution time.