22 Jan
2008
22 Jan
'08
5:27 p.m.
On Tue, 2008-01-22 at 20:40 +0200, Juuso Alasuutari wrote:
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 <rah(a)bash.sh>
On Tuesday 22 January 2008 19:18:10 Nedko Arnaudov
wrote:
> Juuso Alasuutari <juuso.alasuutari(a)gmail.com> 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?)