So Im Back From Seashore Because The Weather And
(Nedko Arnaudov`s blog)

So I’m back from seashore because the weather and I’m going to dedicate rest of my vacation to Linux Audio software. The tempting goals are JACK MIDI support for QMidiArp, support for multiclient apps in ladish, jack-session support in jackdbus and ladish, and LASH support in ladish.

For JACK MIDI QMidiArp, close cooperation with Frank Kober is required but he is in summer mood. Implementing support for multiclient apps makes more sense after or along with adding jack-session support in ladish, because jack-session is designed to support multiclient apps. So I started implementing it, the org.jackaudio.SessionManager interface is now pushed to the js-dbus branch at repo.or.cz jack2 repo. Unfortunately it does not work, all methods fail at JACK API level. I suspect that the session manager API in jack2 is not implemented for in-process (server side) clients, like the one that jackdbus uses. This suspicion is yet to be proven though. Hopefully Stephane Letz will investigate whats going on soon. Until then, I’m thinking about what IPC mechanism would be best for communication between lash-enabled apps and ladish daemon. Original lash implementation used custom messages over sockets, but then 0.6 series switched to D-Bus. I was not really happy with D-Bus used for this because I didn’t and still don’t see any benefits. The old custom IPC code worked well. The situation for ladish is however different. I don’t have legacy IPC code and I cannot easily adapt the LASH one. So I have to either implement a custom IPC mechanism or use some ubiquitous one. And despite the myths flying around, there is only one that matches the requirements - D-Bus.

So it looks it is time for some D-Bus research. First I have to research how D-Bus will behave if there are two “clients”. Some time I’ve asked about this on IRC and the suggestion that I got is to use dedicated D-Bus connection in liblash. I’d like to prove this before implementing ladish`s liblash over D-Bus.

The other topic is async D-Bus calls. As it is now, all D-Bus calls in jackdbus and ladish are synchronous. This is problematic when the call can take long time to execute. For example with (some?) FireWire devices JACK server start can take several seconds. As it is now, the D-Bus loop of services are stalled. No other method calls are possible until the slow operation ends. When this happens UI apps that call methods in jackdbus or ladishd from their main threads are frozen and it is possible that method calls will timeout at client side. The issue will happen during jack-session save too, if some app takes long time to save, or even worse, fails to send reply to jack. It is less likely for jack-session that it is for LASH because jack-session reply has real info in it, as opposed to LASH “save done” reply that does not have any real info. Several LASH apps were (and maybe still are) buggy - they didn’t send the reply event. And then the even worse things happened, LASH became unusable. From what I known about jack-session is that it will freeze just like LASH did. Waiting for “save done” reply event that will never be received. But lets pray that I’m wrong and put this problem aside. The goal is to not block the D-Bus main loop of jackdbus and ladish services. The method call request actually defers execution to a background/worker thread. When the blocking call finishes, it sends the method call reply back, from the background/worker thread. The callers are not stalled as well, they just don’t wait for the reply but are notified when the method call is done. I’ve read on several blog-like and tutorial like places that this is supposed to work. I’d like to verify that such low-level D-Bus async approach actually works though. Alternative would be to implement async semantics over sync calls. Such approach however will prevent existence of clients that want to be simple and kind of stupid, by calling methods async-capable methods synchronously.


Created: Thu Jul 21 22:15:00 +0300 2011

Valid XHTML 1.0 Strict Valid CSS!