[LAD] Summercode 2008: LASH as a D-Bus service

[Nedko Arnaudov]

Bob Ham <rah at 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20080122/25abbf6e/attachment.pgp>