| |||||||||||||
Realtime group scheduling doesn't know JACKRealtime group scheduling doesn't know JACKPosted Jan 4, 2011 17:51 UTC (Tue) by nye (guest, #51576)In reply to: Realtime group scheduling doesn't know JACK by jrigg Parent article: Realtime group scheduling doesn't know JACK
>More to the point, even with large buffers I can't get JACK to work properly _at all_ without RT scheduling privileges
What does 'at all' mean? Like it won't even start? Or it runs but suffers constant underruns? Presumably not the latter since larger buffers should eliminate that problem. Or maybe you mean that without RT you occasionally get such tremendous latency spikes that the buffer size would need to be absurd to avoid them.
Just interested really since the behaviour you see doesn't seem intuitive.
(Log in to post comments)
Realtime group scheduling doesn't know JACK Posted Jan 6, 2011 11:07 UTC (Thu) by jrigg (subscriber, #30848) [Link]
>Or maybe you mean that without RT you occasionally get such tremendous latency spikes that the buffer size would need to be absurd to avoid them.
That's what I meant.
Realtime group scheduling doesn't know JACK Posted Jan 6, 2011 17:26 UTC (Thu) by nye (guest, #51576) [Link]
Thanks for clarifying - though the answer is a little disappointing :P.
Still don't see why JACK would be much worse than common desktop audio systems in this scenario though.
Realtime group scheduling doesn't know JACK Posted Jan 6, 2011 18:23 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
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.
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.
Realtime group scheduling doesn't know JACK Posted Jan 9, 2011 13:55 UTC (Sun) by jrigg (subscriber, #30848) [Link]
>Still don't see why JACK would be much worse than common desktop audio systems in this scenario though.
Right now I'm working on a recording with over 30 separate tracks of 48kHz audio, most of which have separate instances of DSP working on them. This is a fairly moderate track count. I don't see normal desktop audio creating this level of system demand very often (if at all), but it's everyday stuff in recording.
|
|||||||||||||