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

[Juuso Alasuutari]

I'm getting the feeling that there have been some misunderstandings in this 
discussion. Let's see if I can help with them, or if I'll just end up 
confusing things more. :)

On Wednesday 23 January 2008 00:18:48 Bob Ham wrote:
> On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov wrote:
> > Bob Ham <rah at bash.sh> 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?

I don't think Nedko's proposal is motivated by a desire to work around 
existing bugs. Sure, abstracting the LASH <-> JACK interface with D-Bus may 
result in a less crash-prone lashd (i.e. if jackd goes down it won't take 
lashd with it), but this is hardly the point. And I don't think that it would 
cause the users to develop an indifferent attitude towards sound server 
crashes. (For that we'd have to write an autorestart-on-crash feature that 
would prevent any hiccups in the sound stream. :))

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

If such a layer could be beneficial (which is my belief also), why do you 
think that it's outside the scope of LASH planned improvements?

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

I personally don't see LASH as the centre of the audio system, and I'm not 
sure that Nedko meant to say that either.

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

I think we all agree on that. LASH isn't the controller application, it's 
something that a controller application needs to fulfill its purpose.

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

Yes, at least I would like to see the day when one application can manage 
everything that the concept of an "audio session" includes (Patchage is 
probably pretty good already). But you've misunderstood the purpose of this 
discussion. We're not out to turn LASH into a super daemon/application of the 
sort that you're worried about. What we are trying to do is to think of how 
the interfaces and features of LASH could better help support a controller 
application's operation.

Juuso