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

On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov wrote:
> Bob Ham <rah@email-addr-hidden> writes:
>
> > More generally, LASH isn't a frontend for JACK.
>
> What about the jack watchdog? What does get killed by it?

A good example. What does the watchdog do, exactly? It isn't a
frontend. I doesn't try to work around jackd's crashing. It just
ensures that if something bad does happen, the computer as a whole isn't
brought down. This is massively different from what you're proposing.

To try and work around a crash in jackd and present a system to the user
where crashes make no difference is to invite more problems. If you
can't get jackd to stay up, what makes you think you can get your new
system to stay up?

> And actually, in my vision, LASH *should* be frontend to JACK.
>
> > 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.

What you're talking about here isn't really a frontend for JACK, but an
abstraction layer. A layer that abstracts away the incidental
obligations of being a JACK client would be good but that is very far
from the domain that LASH is intended to help with.

To view LASH as the centre of a linux audio system is to misunderstand
its purpose. It might be able to *facilitate* a unified system, along
with JACK and other APIs, but it isn't the unified system itself. Such
a role is intended for the much-loathed "server interface" distinguished
in the LASH API.

Patchage was always the intended style of interface for managing LASH
sessions and the audio system as a whole. LASH implements the
infrastructure necessary for such a system, but it doesn't implement the
system itself. It doesn't provide a patch-connection abstraction; it
doesn't try to start and stop jackd.

It seems that what you want is Patchage++. Unfortunately, LASH isn't
that and I think you're likely to run into problems if you try and turn
it into that.

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

Just out of curiousity, how?

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