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. > * 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. > * 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. > * 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. > * 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. 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
