On Tuesday 22 January 2008 19:18:10 Nedko Arnaudov wrote: > Juuso Alasuutari <[EMAIL PROTECTED]> 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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
