Menu
▾
▴
linuxsampler-devel
|
From: <le...@rd...> - 2004-09-04 07:24:40
|
> > 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 ! How difficult would it be to have a multiple audio engine model in the current version in order to test this idea? Stephane |
|
From: <le...@rd...> - 2004-09-05 06:00:02
|
> > 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 |
|
From: Christian S. <sch...@so...> - 2004-09-05 10:11:58
|
Es geschah am Sonntag, 5. September 2004 07:59 als St=E9phane LETZ 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 yet, tha= n=20 it would pick up a free job by itself instead of just waiting for the other= =20 threads 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. Sure, if you just use the JACK driver then you'll be fine. But there will b= e=20 many other audio drivers for LS and which of them support multi threading o= n=20 their side? So nothing against the multi threading approach on JACKs side,= =20 but we need a general, driver independent solution one day anyway. CU Christian |
|
From: <le...@rd...> - 2004-09-05 18:21:01
|
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 |
|
From: <le...@rd...> - 2004-09-05 06:08:27
|
> > > --__--__-- > > 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 |
|
From: Christian S. <sch...@so...> - 2004-09-04 10:11:01
|
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 |
|
From: Robert J. <rj...@sp...> - 2004-09-04 11:46:32
|
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. But you think there is a way?=20 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 That would be a great feat indeed!=20 Though, at the moment I don't own any dual systems... it would have been gr= eat=20 to try and help out... /Robert > > How difficult would it be to have a multiple audio engine model in the > current version in order to test this idea? > > Stephane > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel =2D-=20 http://spamatica.se/music/ |
Thanks for helping keep SourceForge clean.
X