On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov wrote: > Bob Ham <[EMAIL PROTECTED]> writes: > > > More generally, LASH isn't a frontend for JACK. > > What about the jack watchdog? What does get killed by it?
A good example. What does the watchdog do, exactly? It isn't a frontend. I doesn't try to work around jackd's crashing. It just ensures that if something bad does happen, the computer as a whole isn't brought down. This is massively different from what you're proposing. To try and work around a crash in jackd and present a system to the user where crashes make no difference is to invite more problems. If you can't get jackd to stay up, what makes you think you can get your new system to stay up? > And actually, in my vision, LASH *should* be frontend to JACK. > > > Applications themselves should cope > > with JACK parameters that don't match their saved state. They need to > > cope with that regardless of LASH. > > Unless LASH is a frontend to JACK ;) Apps can cope, but should not be > forced to. What you're talking about here isn't really a frontend for JACK, but an abstraction layer. A layer that abstracts away the incidental obligations of being a JACK client would be good but that is very far from the domain that LASH is intended to help with. To view LASH as the centre of a linux audio system is to misunderstand its purpose. It might be able to *facilitate* a unified system, along with JACK and other APIs, but it isn't the unified system itself. Such a role is intended for the much-loathed "server interface" distinguished in the LASH API. Patchage was always the intended style of interface for managing LASH sessions and the audio system as a whole. LASH implements the infrastructure necessary for such a system, but it doesn't implement the system itself. It doesn't provide a patch-connection abstraction; it doesn't try to start and stop jackd. It seems that what you want is Patchage++. Unfortunately, LASH isn't that and I think you're likely to run into problems if you try and turn it into that. > >> * lash should be able to manage not lashified apps at least to extent > >> of launching them and connecting their ports. > > > > The problem here is that there's no way to know which ports belong to > > the app. > > JACK *will* be improved (at least its dbus-interface) to fix this issue. Just out of curiousity, how? Bob -- Bob Ham <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
