[linux-audio-dev] Re: jack, low latency and IO

Jens M Andreasen jens.andreasen at chello.se
Tue Dec 7 18:01:18 UTC 2004


On tis, 2004-12-07 at 17:54 +0100, Artem Baguinski wrote:

...
...

> forget the gui, suppose i meant that MIDI button.
> 
> JACK does everything to make sure the audio threads run uninterrupted
> to process that audio on time and deliver it to the audio hardware,
> right? but it doesn't make sure other IO gets handled on time. 
> 
And here we mean specifically that MIDI button, and not the general case
of IO (and definately not some randomly slow block-device ...)

> If I make sure there's enough CPU cycles for everybody why do audio
> threads require real time priority? ...

Low priority processes are only idle untill something happens that can
make them work. Say you want to have a look at your mailbox while your
audioapp is running, right? It will be OK that X (rendering your mail)
is not quite as snappy as it use to be when it is on its own, but it
would be very disturbing if your sound cracked up because jack had to
share cycles evenly with your mailapp.

>                                  ... to make sure audio gets delivered
> to the hardware ASAP, right? but the handful of bytes from my moving a
> MIDI slider has to be delivered and taken into account on time as
> well, otherwise I still have delay between my action and synth's
> reaction. 


> so I want my input thread to run just as often as audio
> thread, no? ...

I think you will have to or else the internal state of your app will not
be in sync with the outside world.

>          ... in this case suggestion of Jens (running MIDI [or input]
> thread with the same priority as audio thread) seems the best i could
> do. Only MIDI thread will do its job much quicker.
> 
> or am i missing something?
> 
> like, if each JACK application starts adding extra real time threads
> they all will suffer from the same problems they would if they werent
> real time scheduled?

Well, if those other apps starts indiscriminately adding desk-IO and
major repaints in realtime then, yes you would be in trouble. But what
we are talking about here is processing 'a handful of bytes' every ms or
so from a device with known (near)zero-latency. This will have a very
limited impact on overall performance.


mvh // Jens M Andreasen






More information about the Linux-audio-dev mailing list