Bob Ham <rah@email-addr-hidden> 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>
_______________________________________________
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:22 EET