7 Dec
2004
7 Dec
'04
5:33 p.m.
On tis, 2004-12-07 at 16:42 +0100, Artem Baguinski wrote:
...
...
Given that your devices have a known worst-case latency within your
specified timing requirements, you can give them realtime priority.
I believe that reading the state of RS-232, like you suggested, is
perfectly safe.
It makes sense to read all your devices from one thread. It might save
you a context-switch (or two or ...) It can also give you a guarantee of
some kind of order if you need it.
On the other hand, a design with individual threads reading from each
IO-stream will be easier to maintain, and if there is nothing going on
there currently, the thread will block and be out of the runable loop,
hence leaving it up to the real-kernel-pro's to optimize your app.
Personally I have a mutex to protect me while the voice-stealing
algorithm is doing its magic, so I might have a look into the single-
thread variant ... perhaps. The mutex is not *that* expensive.
The mouse-down, mouse-dragged signals (and friends) fits within realtime
constraints. It is the 'do_running_fading_ink_repaint()' (or whatever)
that you need to keep low priority, albeit probably above Mozilla
repainting some nasty ads on its current page.
MIDI
buttons/sliders do not need to have any noticeable latency if the
MIDI-thread is run at the (near?) same priority as jack. Although the
thread has high priority, it is mostly idle and will consume next to no
CPU.
Suppose JACK consumes 90% of your CPU, you will have 10% left to do your
MIDI IO, which is plenty for processing a handful of bytes.
so i suppose this will be still valid for any other input... i see.
Suppose I have several various devices that control various aspects of
sound generation / processing. they all send "handful of bytes" now
and then and I want my JACK client to react immediately. Does it make
sence to have one high priority "input thread" to handle all of them?
Shall I request real time scheduling for this thread(s)?
GUI buttons on
the othe hand are expensive to repaint by nature, and the
cost depends on what kind of eye-candy your installed GUI-theme will
use.
I was talking about delay between the acttion of the user [mouse
button click in this case] and reaction of the sound generation /
processing stuff. I don't really care if button gets redrawn half a
second later if the effect starts right after i click. But I suppose
I'd think twice what sort of GUI controls and feedback to use
now. thanks again.