On Tue, 2008-01-22 at 20:40 +0200, Juuso Alasuutari wrote: > On Tuesday 22 January 2008 19:18:10 Nedko Arnaudov wrote: > > Juuso Alasuutari <[EMAIL PROTECTED]> writes:
> > > This is where I believe we both agree that turning LASH into a D-Bus > > > service will help. The session handler shouldn't be a JACK client; > > > instead, the audio server should be a D-Bus client of the session > > > handler, although a Very Special one. And that's something that the JACK > > > D-Bus control interface will enable. I don't think this is necessary, or the right way to do it. All LASH needs is a way to determine which JACK (or ALSA seq, etc) client corresponds to which LASH client, how they are interconnected, and a way to connect different clients together. These APIs exist already, they're well defined and many applications use them. It's also a little presumptuous to assume that LASH will be the only program that would require such functionality. So I'm not sure what benefit adding LASH support to jackd et al would have. The best way to have the patch connection system as a D-Bus LASH client would be to implement a bridge that interfaces with the existing patch system APIs on one side and the LASH server on the other. In which case, why bother with a bridge at all? You end up back with LASH supporting the patch connection system, instead of the other way round. > > Yes, except that I was thinking about not trating JACK server as LASH > > client. Instead LASH should directly support and have special handling > > of JACK server. > > I didn't mean that JACK would be just another ordinary client for LASH; lashd > would naturally have special handling for it. Lashd would communicate with > jackd using the D-Bus interface that we're working on now. What I did mean > was that lashd shouldn't be a "JACK client" in the usual sense of the word > anymore, i.e. no libjack dependency. I believe this is what you meant also? > > (I can see now as I'm writing this that Bob Ham is expressing a different > opinion on the list, maybe he'd like to comment on this further?) Indeed, LASH already does have special handling of the JACK server. Too much special handling, in fact, as some API functions have the word "jack" in them, which is just bad. The only thing that JACK-DBus changes from LASH's perspective is that it would need to make different calls to create port connections and to register its interest in graph changes. This isn't a big problem. Bob -- Bob Ham <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev