7 Dec
2004
7 Dec
'04
12:53 p.m.
"Jack O'Quin" <joq(a)io.com> writes:
yep, this is what i'm puzzled about.
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.
If I make sure there's enough CPU cycles for everybody why do audio
threads require real time priority? 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? 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?
.. your
audioapp should repaint itself before any less urgent
process (with normal or slightly high priority) gets a chance at the
CPU. JACK will still run at (near?) highest priority, so if your
audio-processing demands 90% CPU there will be not so much
repainting going on ...
As a practical matter, JACK had better *not* be using 90% of your CPU.
That sort of load is unlikely to be reliably sustainable.
For any reasonable CPU load, there should be plenty of cycles
remaining to run non-realtime threads without requiring special
scheduling hacks. Don't forget that other system resource
bottlenecks can cause poor
performance. When running realtime, JACK locks down large amounts of
memory. Your GUI code may be getting paged out.
--
Artem Baguinski: http://www.artm.org/
V2_Lab: http://lab.v2.nl/
V2_ Organisation for the Unstable Media: http://www.v2.nl/