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

Hi,

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

> 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 SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev

_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Thu Aug 19 00:15:02 2010