| |||||||||||||
Realtime group scheduling doesn't know JACKRealtime group scheduling doesn't know JACKPosted Dec 22, 2010 19:52 UTC (Wed) by jrigg (subscriber, #30848)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. These methods aren't always available, but in a pro recording situation they often are.
The most important reason for realtime scheduling privileges IMO as an audio engineer is to ensure that nothing gets in the way of audio throughput or processing. Just increasing buffer size is not an option beyond a certain point, as it is limited by the interface hardware. JACK was designed for pro audio (the fact that hobbyists and non audio engineers also use it is a side issue) and needs to perform reliably enough for those of us whose jobs depend on it.
(Log in to post comments)
Realtime group scheduling doesn't know JACK Posted Dec 22, 2010 19:56 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
that assumes that you have an analog signal at some point to tap into and monitor.
increasingly things are digital for large portions of the path, and may only become analog when they go to the amplifiers.
Realtime group scheduling doesn't know JACK Posted Dec 22, 2010 20:42 UTC (Wed) by jrigg (subscriber, #30848) [Link]
Yes things are increasingly digital, but I've never seen a situation in my work where there wasn't an analog signal available somewhere, even if it's only a microphone preamp output. I'm aware that there are microphones that give a digital output, but so far their market penetration in pro audio is very small.
My main point was that low latency isn't the only reason for requiring RT privileges.
Realtime group scheduling doesn't know JACK Posted Dec 22, 2010 20:59 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
I wasn't thinking in terms of micraphones, but in terms of digital instraments that only output MIDI and it's not until much later that there is any analog.
but I agree that low latency isn't the only reason.
Realtime group scheduling doesn't know JACK Posted Dec 22, 2010 20:41 UTC (Wed) by jebba (✭ supporter ✭, #4439) [Link]
> 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).
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.
|
|||||||||||||