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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: jack, low latency and IO
From: Jens M Andreasen (jens.andreasen_AT_chello.se)
Date: Tue Dec 07 2004 - 23:33:21 EET


On tis, 2004-12-07 at 16:42 +0100, Artem Baguinski wrote:

...
...

> > 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)?
>

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.

> > 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.

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.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Dec 07 2004 - 23:38:08 EET