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

On Tuesday 22 January 2008 19:18:10 Nedko Arnaudov wrote:
> Juuso Alasuutari <juuso.alasuutari@email-addr-hidden> writes:
<snip>
> > Idiot-proof capturing of stdout/err could probably only work if the
> > client process was executed from a wrapper. It could be accomplished with
> > the D-Bus service file, though. If all clients' service files would be
> > mandated to include something like "Exec=/usr/bin/lash_exec
> > /usr/bin/foobar", then... Umm, at least we could redirect the streams
> > _somewhere_ -- but what to do from thereon, I'm not sure.
>
> I was thinking about "sending" client stdout/stderror to log file (with
> prefixing). I dont think we need to require registering of one dbus
> service per lashified client (autolaunching). Also IMHO there is nothing
> wrong with just capturing stdout/stderr of launched clients. Of course,
> liblash (dbus version) will start lash service to provide "callbacks" for
> the lash API.

Hmm, I think I went too far with ideas about clients being auto-launched by
D-Bus. It would add complexity, demand that the clients register as services,
etc. And what a horrible mess it would be to try to launch more than one
instance of a client...

So if we don't have to change the way autolaunching happens now, things are as
simple as Bob Ham put it in his reply: just point stdout/err to a log file
after fork()'ing. That would be accomplished with a rather simple patch.

> >> * lash is of mercy of libjack and crashing jackd often causes lashd
> >> kill. This is just wrong. lash should be able to restart jack, tell
> >> jack apps that jack server is started again so they can reconnect to
> >> jack server and finally lash can restore jack connections.
> >> * 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 where I believe we both agree that turning LASH into a D-Bus
> > service will help. The session handler shouldn't be a JACK client;
> > instead, the audio server should be a D-Bus client of the session
> > handler, although a Very Special one. And that's something that the JACK
> > D-Bus control interface will enable.
>
> Yes, except that I was thinking about not trating JACK server as LASH
> client. Instead LASH should directly support and have special handling
> of JACK server.

I didn't mean that JACK would be just another ordinary client for LASH; lashd
would naturally have special handling for it. Lashd would communicate with
jackd using the D-Bus interface that we're working on now. What I did mean
was that lashd shouldn't be a "JACK client" in the usual sense of the word
anymore, i.e. no libjack dependency. I believe this is what you meant also?

(I can see now as I'm writing this that Bob Ham is expressing a different
opinion on the list, maybe he'd like to comment on this further?)

> >> * there is no export/import "tarball" (single file) functionality, to
> >> be used for backup of sessions and transfering them between machines
> >> * lash apps should be allowed to do "light save", with app session
> >> referecencing files/resources external to lash. This means for
> >> example that such lash light save should not copy ardour wav files
> >> that are linked (not copied) to lash directory.
> >
> > These sound like they could be useful features. However, I feel that we
> > should settle on the more basic issues first.
>
> What are they? :)

We're discussing them now. :)

> > At this point I believe it would help to categorize the different
> > sub-goals. What issues are purely in the domain of API design, what are
> > the things that the daemon must handle, etc. I'll start sketching these
> > and getting familiar with what we have now, then post some sort of rough
> > draft. In the meantime I'll be happy if anyone wants to comment on the
> > questions above.
>
> If you are talking about the liblash API, I'm oposed to breaking
> it. OTOH, I think we could extend it or provide alternative API. We dont
> need to kill lash pupil apps, right? :)

Right. But introducing D-Bus and all that it entails into the soup will
complicate things if the first priority is to keep the API identical.

For instance, a client which communicates LASH events via D-Bus will need a
D-Bus event loop. Let's say we implement a completely transparent D-Bus event
loop into liblash which is launched by lashdriver_init(). Now, if the client
wants to manage other various D-Bus connections on its own, there will be two
event loops running within the same process.

If a client wants to handle its LASH events using QtDBus or DBus-GLib then
lashdriver_init() shouldn't try to handle everything. And on the other hand,
I'd be happy to use a library which provides a D-Bus event loop and event
handling for LASH clients, instead of having to write one from scratch.

Juuso
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Jan 23 04:15:17 2008