| |||||||||||||
Realtime group scheduling doesn't know JACKRealtime group scheduling doesn't know JACKPosted Dec 22, 2010 20:41 UTC (Wed) by jebba (✭ supporter ✭, #4439)In reply to: Realtime group scheduling doesn't know JACK by jrigg Parent article: Realtime group scheduling doesn't know JACK
> There seems to be quite an emphasis on low latency in this discussion. When recording, the issue of latency can be side stepped by monitoring direct from the mixing desk or microphone preamp, or if your interface permits, low latency monitoring from its internal hardware.
Yes, it can be done that way, but if you *do* have low latency it can be easier to do it all in ardour's mixer. I would set up an ardour channel for each set of headphones and send a different mix depending what the person wanted (e.g. a bassist and vocalist may want to have different instruments emphasized).
(Log in to post comments)
Realtime group scheduling doesn't know JACK Posted Dec 22, 2010 21:01 UTC (Wed) by jrigg (subscriber, #30848) [Link]
Low latency can be useful as you say. On my own systems I've never worked that way, but I'm aware that many do.
More to the point, even with large buffers I can't get JACK to work properly _at all_ without RT scheduling privileges, so low latency is a bit of a distraction in this argument IMO. JACK needs RT privileges just to work reliably without being pushed aside by anything else the system might be doing.
Realtime group scheduling doesn't know JACK Posted Jan 4, 2011 17:51 UTC (Tue) by nye (guest, #51576) [Link]
>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.
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.
|
|||||||||||||