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

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

>
>
> --__--__--
>
> Message: 3
> From: Robert Jonsson <rj...@sp...>
> To: lin...@li...
> Subject: Re: [Linuxsampler-devel] Re: GSt3 is out - does not support 
> multiple
> Date: Sat, 4 Sep 2004 13:46:01 +0200
>
> l=F6rdagen den 4 september 2004 09.23 skrev St=E9phane LETZ:
>>> Message: 1
>>> Date: Fri, 03 Sep 2004 06:57:39 -0700
>>> From: Mark Knecht <mk...@co...>
>>> To: Linux-Sampler <lin...@li...>
>>> Subject: Re: [Linuxsampler-devel] GSt3 is out - does not support
>>> multiple
>>>  processors
>>>
>>> Mark Knecht wrote:
>>>> Apparently is doesn't run on a multi-processor box, and if you have 
>>>> a
>>>> hyper-threading P4 you have to turn that off.
>>>>
>>>> Hey - another opportunity for LS!
>>>>
>>>> - Mark
>>
>> 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 !
>
> Sounds very interesting!=20
>
> As I understand it the common view is that multiprocessing and 
> lowlatency d=
> o=20
> not match.

Why?

> But you think there is a way?=20

I have a Jack multi-processor version on MacOSX that run very well! At 
64 frames without problems on a dual 1.8 Ghz G5.

Basically there is no fundamental difference in having several Audio 
clients (like CoreAudio clients for example) running together on a 
machine (a setup that you can perfectly done on MacOSX with regular 
applications) and the Jack for multi-processor model.


> Having it in jack sounds almost too good to be true ;). It would mean 
> that=
> =20
> different client could run in different threads, on different CPUs, as 
> long=
> =20
> as their graphs are parallell right?=20

Exactly! This is the idea.

The activation model is now more  a "data-flow" model. Each client 
maintains a input dependency counter (the number of input client it 
depends on)
and clients are made runnable (and thus possibly executed on the first 
available processor) as soon as all their input clients have been 
runned.

Stephane