| |||||||||||||
Realtime group scheduling doesn't know JACKRealtime group scheduling doesn't know JACKPosted Jan 6, 2011 18:23 UTC (Thu) by dlang (✭ supporter ✭, #313)In reply to: Realtime group scheduling doesn't know JACK by nye Parent article: Realtime group scheduling doesn't know JACK
because int he professional use, jack needs to get audio input, process it, and play the modified version to the same people who can hear the audio input.
that means that the total latency that can be tolorated is less than for a normal desktop app, so the buffers can't be as large.
(Log in to post comments)
Realtime group scheduling doesn't know JACK Posted Jan 10, 2011 13:58 UTC (Mon) by nye (guest, #51576) [Link]
I understand that, but that wasn't the situation described by the poster upthread, who pointed out explicitly that low-latency was not the issue. For clarity's sake, this is how I interpreted the situation described, as accurately as I can manage:
There exists at least one choice of buffer size which is sufficient for at least one possible purpose, with which it is possible to get skip-free audio using other sound systems on a normal kernel, but only on a real-time kernel using JACK.
Realtime group scheduling doesn't know JACK Posted Jan 10, 2011 14:04 UTC (Mon) by nye (guest, #51576) [Link]
Should have added: and the answer is that there's another variable which makes it an unfair test, strictly speaking. Nobody [sensible] is using JACK in the cases where a normal desktop system would suffice, so it's only ever used under a higher load where the variance in latency can apparently be extremely large.
Realtime group scheduling doesn't know JACK Posted Jan 12, 2011 19:33 UTC (Wed) by jrigg (subscriber, #30848) [Link]
FWIW I'm using realtime scheduling capabilities with a standard kernel, not an rt-patched one. Realtime pre-emption as enabled by the rt-patch is not what is being discussed here, just the ability to use SCHED_FIFO.
|
|||||||||||||