Re: [ecasound] race condition: engine-launch, jack-connect

Excerpts from Philipp Überbacher's message of 2010-08-02 10:14:50 +0200:
> Excerpts from Joel Roth's message of 2010-07-31 07:50:52 +0200:
> >
> > On Thu, Jul 29, 2010 at 12:46:59AM +0200, Philipp wrote:
> > > Hi,
> > > I spent a lot of time today trying to find a very weird bug.
> > >
> > > "jack-connect LinuxSampler:0 ecasound:in_1"
> > >
> > > When I sent the string manually ecasound connected properly, when I
> > > scripted it it didn't. I did the same thing but the result was
> > > different. I looked for quite some time, trying to figure out whether I
> > > missed something and did something different by accident but couldn't
> > > find anything. Ecasound running with -ddd gave me the necessary hint:
> > >
> > > (jack-connections) Connected JACK ports LinuxSampler:0 and ecasound:in_1
> > > with result of -1
> > >
> > > In the manual case the result was 0. This told me that the message
> > > arrived in both cases. The preceding commands were identical, so the
> > > only explanation was that it's a timing problem. And indeed, sleeping
> > > for 0.1s between the engine launch and the connect message caused the
> > > connection attempt to succeed.
> > >
> > > I consider this a bug in ecasound. Imho it should wait until the engine
> > > is ready before it attempts to connect, simply to avoid this race
> > > condition. An easy way to get a notification about the failed connection
> > > attempt would help and also help when it fails for other reasons, but if
> > > it exists I haven't found a way to get this notification yet.
> > > Documenting this behavior would help as well, and so does the sleep()
> > > hack but I consider all this a workaround, not a solution.
> >
> > Hi Phillip,
> >
> > You can connect Ecasound to a JACK client without invoking
> > jack-connect. Ecasound can do this directly:
> >
> > ecasound> add-ai jack,LinuxSampler
>
> Thanks, I thought 'system' was a special case, but apparently, it's not.
>
> ai-add jack,<some_jack_client_name> is convenient, but not usable in
> every case. The nice thing about is that you can issue it before
> engine-launch, ecasound doesn't need to be an active jack client yet.
> It probably does some pattern matching and connects to the first two
> (didn't test with other cases) ports of that client. If the client has
> more ports and you want something else, you need jack-connect. I don't
> know why it isn't affected by this race condition, maybe Kai took care
> of it in this case by waiting until ecasound is an active jack client,
> or maybe it just takes long enough.
>
> The main reason why I do connections from my program is because I made a
> stupid design decision, I tear down the chain-setup all the time, and
> after I fixed that I won't need it for a while. Maybe someday I'll write
> a user definable regex based autoconnect, similar to what VLC does.
>
> Talking about tearing down chain-setups, this reminds me of another
> strange observation. Apparently audio in/outputs keep hanging around
> when you delete a cs. They are connected to no chain-setup, but still
> are there and can get in the way. I find this weird, because a cs is
> supposed to be the mother element, and I was expecting all its children
> to be removed with it.
>
> > In my view, Ecasound requiring some time to respond to
> > commands before an external program may be invoked that is
> > dependent on the effects of those commands does not seem
> > serious or even unexpected.
> >
> > In general I notice that Ecasound enables functionality, but
> > does not by any means trap commands that may trigger an
> > error condition.
> >
> > As I understand it, the task of ensuring that Ecasound
> > behaves in a friendly way to the naive user falls mainly to
> > user-interface developers. :-)
> >
> > At the same time, I would welcome such changes to Ecasound
> > as would make it more resistant to user error or ignorance
> > of Ecasound's behavior.
> >
> > Probably Kai would welcome patches. :-)
>
> It was really hard for me to find this one, I didn't expect a race
> condition, and since I'm rather unsure about my programming skills I
> looked everywhere else first a couple of times :)
>
> It will be a while until I've made my way from lua to C to C++, but
> maybe it's not too hard in this case. I guess there's some way for a
> client will be notified when it is an active jack client, and that
> should be all that's necessary.
>
> Regards,
> Philipp
> --
> Philipp
>
> --
> "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
> und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan

A while back I wrote that ecasound still uses the long deprecated
jack_client_new. It seems like it might be part of the problem. If I
understand the API description correctly, the new jack_client_open
returns a status, which probably could be used to determine the success
of the operation.
http://jackaudio.org/files/docs/html/group__ClientFunctions.html#ga28977ad0cccf08cd600dd220e2b1c880

Regards,

-- 
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Ecasound-list mailing list
Ecasound-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list