Recent Features
| |||||||||||||
Realtime group scheduling doesn't know JACKRealtime group scheduling doesn't know JACKPosted Dec 22, 2010 12:25 UTC (Wed) by drag (subscriber, #31333)In reply to: Realtime group scheduling doesn't know JACK by jimparis Parent article: Realtime group scheduling doesn't know JACK
> That's my whole point -- there is a whole world of other systems that (to me) seem much more demanding than audio processing, like video input and output, and gaming, that don't seem to have the realtime requirements or problems of JACK. I'm trying to understand exactly what the audio use cases are that make processing 48 KHz data so difficult. And it seems like the answer is the specific case of live looping back audio from input->output which needs low latency.
It's not just _LOW_ latency.
Realtime configurations give you the ability to _CONTROL_ latency.
That's the point.
Often stuff running realtime will have significantly worse performance then if you had them in the normal configuration.
Linux is designed to provide high throughput and work efficiently under high loads. The design choices and compromises that goes into making Linux behave well and perform well under high loads is COUNTERPRODUCTIVE to providing good realtime performance.
It's not a question on how demanding the workload is, it has to do with your ability to control how often something happens and when it happens.
THAT is what realtime performance is about. Not making your system work faster, quicker, or perform better... it's just a question of being able to control latencies. Without realtime configurations you can see latency spikes up to 250msec or more on a regular basis for Linux. It's just a nature of the beast.
And of course even with Linux in 'realtime mode' it's not perfect and can't guarantee you with 100% latency control.. Linux is far too complicated for that, but it does help tremendously.
(Log in to post comments)
|
|||||||||||||