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