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