Re: [LAD] Summercode 2008: LASH, pt. 3

Fons Adriaensen wrote:
> On Sat, Feb 02, 2008 at 08:22:20PM +0200, Juuso Alasuutari wrote:
>
>> 1) Switch to using the JACK D-Bus interface for lashd<->jackd communication.
>
> Paul D. has already replied to this...
>
>> 2) Add a D-Bus control interface to LASH, which is supposed to
>> eventually replace the current liblash server interface API.
>
>> 3) Change the liblash client interface's internals to use D-Bus for
>> communication with lashd.
>
> I fail the see the advantage of D-Bus over e.g. OSC via UDP or TCP.
> Last time I looked at the lash sources, the protocol was really
> just one small step away from OSC - it would have taken an hour
> or two to do the conversion.

The core issue is abstracting the interfaces involved. As long as it
serves to free LASH from being a libjack client, and the LASH control
apps from being liblash clients, I'm OK with whatever acronym finally
slips in.

That being said, I still do favor D-Bus over OSC. IMHO it's the best
suited candidate for these kind of desktop purposes (autolaunching being
a definite plus as Nedko pointed out). A D-Bus interface would guarantee
less painful integration with all sorts of frontends and wizards.
(Surely you'd like to manage your sessions through a KDE4 plasmoid using
neat composite effects? :))

Adding an internal, generic generic control interface to LASH would
probably be a good idea anyway. Nedko is already working on an internal
interface for JACK which allows different external control interface
implementations to co-exist. This kind of solution would effectively
keep LASH from being hijacked by any particular protocol implementation.

> Other consideration: any form of session management for the
> systems I'm using would have to be at least a two-layer affair.
>
> There is a first layer of 'system' apss talking to jack and
> creating a working environment - this is all monitoring and
> rendering stuff.
>
> The second level is user sessions, also consisting of several
> apps talking to jack. They *use* this existing environment but
> should not be allowed to modify it.
>
> For anything like lash to be useful here it would need to support
> this layering.

Can you give specific examples of what you mean by this layering concept?

Juuso
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Feb 4 20:15:03 2008