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

From: Kai Vehmanen <kvehmanen@email-addr-hidden>
Date: Wed Aug 18 2010 - 23:39:16 EEST


On Mon, 2 Aug 2010, Philipp ‹berbacher wrote:

> 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

well, there's also "jack_multi". You can add multiple "jack_multi"
input/outputs to a single chainsetup (with different channel counts) and
specify each port connection separately. E.g.

ecasound -a:1,2 -i 4ch-file.wav \
          -a:1 -f:,1, -o jack_multi,app1:in_1 \
          -a:2 -f:,3, -o jack_multi,app2:in_1,app2:in_1,app3:in_1

So this routes a 4 channel audio stream via two ecasound chains (mono '1'
and the three channel '2'). The JACK connections are setup on a per-port
basis and sent to three different JACK clients.

The above requires 2.6.0 or newer (empty -f options and jack_multi

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

I'd recomend 'jack_multi' just for this reason. The part of ecasound that
implements "jack-connect" and the one implemeting "engine-launch" are
completely separate and do not know about each other (e.g. "jack-connect" is just
like the command-line jack_connect tool).

Ideally ecasound would have a more complicated JACK connection manager.
You'd register connections you want to make, and then ecasound would
monitor any JACK port addition/removals and make connections if they match
the application requests. But this goes beyond what ecasound is capable
currently (jack-connect just tries to connect now and jack-list-connectins
shows what happened), and this would be duplicating existing code (like
qjackctl patchbay and others).

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

This sounds like a bug. The audio in/outs should go when you remove a
chainsetup. A bug report is very much welcome if you can reproduce this
with some steps.

This email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge

Ecasound-list mailing list
Received on Thu Aug 19 00:15:02 2010

This archive was generated by hypermail 2.1.8 : Thu Aug 19 2010 - 00:15:02 EEST