[Linuxsampler-devel] Re: GSt3 is out - does not support multiple

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

>
> Es geschah am Samstag, 4. September 2004 09:23 als St=E9phane LETZ 
> schrieb:
>> I'm working on a multi-processors version of Jack. Would it be a way 
>> to
>> add  multi-processors  support to LS?
>> For example if LS would be able to run multiple audio engines driven 
>> by
>> multiple jack clients, then LS could be multi-processors !
>>
>> How difficult would it be to have a multiple audio engine model in the
>> current version in order to test this idea?
>
> Each engine on each sampler channel is independent already. The thread 
> /=20
> process context solely comes from the audio output device (=3Ddriver) 
> the=20
> respective engine is connected to. So you would only have to modify 
> the JAC=
> K=20
> driver in LS a bit to be able to test it.
>
> But I wonder if it wouldn't be better to implement a driver 
> independent=20
> solution. Because copying the audio data to the final driver output 
> buffer=
> =20
> doesnt take much CPU time. Most of the CPU time is used for rendering 
> the=20
> data in each engine. So I would propose to implement a job dispatcher 
> in th=
> e=20
> AudioOutputDevice base class which distributes jobs for calling 
> threads. So=
> =20
> there would be a fix number of threads (which can be set by the user) 
> which=
> =20
> just poll the AudioOutputDevice base class for scheduled render jobs 
> and th=
> e=20
> driver thread itself asks the AudioOutputDevice class if all jobs are 
> alrea=
> dy=20
> done, if not it will also take a free job and poll again if all jobs 
> are=20
> done. Finally when all jobs are done, the driver thread will just copy 
> the=
> =20
> audio data to the driver output buffer.
>
> Anyway, no matter what you do, please wait a bit til committing 
> something l=
> ike=20
> that to CVS. I'm currently working to get things stable for the 
> first=20
> release.
>
> CU
> Christian

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?

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

Moreover having the Jack client manage multi-threading alows the Jack 
server to possibly knows how many threads are used by each client, 
which may be of importance (for example each you have a Jack client 
graph where each client is multi-threading itself, at some point it is 
useless to have two many threads, that is more threads in parallel  
than the number processors available.)

And having one Jack cleint with several theads is better than having 2 
jack clients, because 2  jack client appears are separate entities for 
connection for example.

Stephane