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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
