Bob Ham <rah(a)bash.sh> 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>