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

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

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. :-)

<snip>

> Philipp

-- 
Joel Roth
------------------------------------------------------------------------------
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@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list