Re: [LAU] [LAD] Update of jconv

On Wed, Dec 02, 2009 at 11:16:30AM +0100, Stéphane Letz wrote:

> So does this mean than going into freewheeling should be
> handled in a special way: like dropping RT mode for
> additional worker threads and so on (then when freewheeling
> stops, you would have to setup RT mode again...)

See my other post - the easiest way would be to make the
main thread wait for the others.

> We could even imagine that JACK could provide some support
> for this kind of requirement : allowing to define additional
> worker threads, automatically handling priority change when
> freewheeling on/off....

It could but I don't think it would simplify matters much.
Supporting many parellel period sizes *would* complicate
Jack a lot.
 
Paul Davis:

> i doubt if applications with such architectures want JACK
> itself to try to micromanage this level of detail. they
> already have to make their own decisions about thread
> priorities.

These priorities maybe need some discussion.

The relative period sizes used by zita-convolver are
either 1:2:8:32 or 1:4:16:64. The first step is either
2 or 4, the others are always 4, and the choice of the
first step is made to make the longest one (if used)
always 8192.

In 1.0.0 each step would decrease the priority by one
relative to Jack's thread. In 2.0.0 this is different:
each doubling of the period will decrease the priority
by one.

This change ensures that threads using the same period
will have the same priority, even if they are not in
the same client. This is absolutely necessary in order
to make two or more such clients work together smoothly
and have 'fair' scheduling. This should become some sort
of 'standard' if more apps start using such schemes.

Threads doing disk-IO probably don't fall in this scheme,
I suspect they always use much larger block sizes, have
plenty of buffering and can run SCHED_OTHER.

Ciao,

-- 
FA
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user