[Linuxsampler-devel] Re: multi threading (was: GSt3 is out - does not support multiple)

[<le...@rd...>]

On 5 sept. 04, at 12:08, Christian Schoenebeck wrote:

> Es geschah am Sonntag, 5. September 2004 07:59 als St=E9phane LETZ=20
> schrieb:
>> But this solution requite LS to implement its own thread management
>> code? I mean LS would create supplementary threads by itself and the
>> Jack callback would have to wait for  the internal thread to finish?
>
> No the JACK client thread would not wait. If not all jobs are done=20
> yet, than
> it would pick up a free job by itself instead of just waiting for the=20=

> other
> threads to finish.

OK. Actually it was already clear in you previous mail.. that I did not=20=

read carefully enough....

>
>> I think all this thread management can be done by Jack itself. After
>> having made this proposition of 2 Jack clients, I think now that a
>> model with only one *single* Jack client with several Audio callback
>> would be better.
>> Basically the idea would be to extend Jack API to be able to=20
>> add/remove
>> several Audio callbacks. Then each thread does its jobs the way you
>> describe, and the Jack client wait for  the 2 threads to finish. The
>> difference is that the  thread management (setting the correct
>> parameter for the real-time for example)  is done by Jack which is
>> better.
>
> Sure, if you just use the JACK driver then you'll be fine. But there=20=

> will be
> many other audio drivers for LS and which of them support multi=20
> threading on
> their side? So nothing against the multi threading approach on JACKs=20=

> side,
> but we need a general, driver independent solution one day anyway.

Sure.
But in a more general point of view I think adding multi threading=20
capabilities in one application (to take profit of multi-processors)=20
without taking account of the outside context the application will run=20=

in, have some inherent limitations.

What happens if a multi threaded LS runs on a machine where other audio=20=

applictions are also competing for the available processors? At some=20
point having too much real-time threads competing is worse that having=20=

less threads.
Basically they will not be able to run at the same time and you may=20
have aditionnal cost like more context-switches for example.

The strengh of the Jack based approach, where *all* audio applications=20=

run under the control of the jack server, is that the server can have a=20=

global view of all running applications. Depending of the connection=20
topology between applications, the server could for example estimate if=20=

there will be two much threads competing for the available number of=20
processors  in one part of the client graph. And possibly notify=20
clients so that they can adapt to the situation dynamically.

These are some vague ideas (that are not part of the jack sever=20
yet...), but I'm sure this is something to further explore for the Jack=20=

server muti-processors version.

Stephane