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 <rah@email-addr-hidden>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
This archive was generated by hypermail 2.1.8 : Wed Jan 23 2008 - 04:15:17 EET