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

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