Bob Ham <[EMAIL PROTECTED]> writes: > On Tue, 2008-01-22 at 15:39 +0200, Nedko Arnaudov wrote: >> * lash is of mercy of libjack and crashing jackd often causes lashd >> kill. This is just wrong. > > You're right, but it shouldn't be worked around. If energy is going to > be expended on this problem, it should be expended on fixing jackd such > that it doesn't crash in the first place. > > If you start working around problems with JACK, I can envision a > situation where there is little motivation to fix bugs in JACK because > the cost of its crashing is so low. > > More generally, LASH isn't a frontend for JACK. LASH (when controlling > JACK clients) relies on services that JACK provides. This isn't a bad > thing. The focus shouldn't be on taking control of jackd through LASH > but in making jackd more server-like, such that you don't need another > server just to control it.
What about the jack watchdog? What does get killed by it? And actually, in my vision, LASH *should* be frontend to JACK. In the same way some good all-in-one apps to that. LASH should behave like all-in-one app in the perspective of connecting to audio hardware, managing "projects", etc. all-in-one multi-process modlar app (system). >> * lash should preserve at least basic properties of currently started >> JACK server, such as sample rate and availability of hardware >> ports. When loading session whose JACK parameters dont match, user >> should be given options what to do. > > This is outside the scope of LASH. 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. >> * 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. >> * lash does not preserve X11 related properties of apps, like on what >> screen (dual-head) they were. > > Nor should it. The X11 system is nothing whatsoever to do with LASH, > intentionally. From LASH's perspective, anything to do with X11 is > entirely the client's responsibility. Adding X11-specific functionality > into the protocol, the server and the library should not happen. > > Providing convenience functions to clients is a solution, eg > lash_x11_get_state_configs() and that returns a set of LASH configs > containing the state of the X11 system. And, of course, functions to > restore the state. But it should be separate from LASH itself, eg, in > some liblash-x11. No, X11 display is managed by app launcher. I guess you already know what DISPLAY environment variable is for. >> * Supporting connections for things other than JACK (read ALSA seq) > > LASH already does support ALSA seq. Future support would be connecting > via netjack, or firewire, or $next_big_thing. Yes and also it already fails for almost everyone to do simple things. ;) -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>
pgpsEtTBan67W.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
