[ecasound] Ecasound JACK interface (was: Re: [ANN] Ecasound/Nama recorder-mixer version 0.975)

On Sun, Jan 04, 2009 at 08:50:48PM +0100, Julien Claassen wrote:
> Hi again!
> Thanks for the kind words.
> But a question here: did you see the latest changes to the ecasound
> JACK interface? Kai changed a bit. Jack_alsa will some time go out of
> business, because it seems to limited anyway. then you should already
> have the ability to name ecasound input/output ports for each chain. I
> think Kai added a parameter to jack or jack_auto, that allows you to give
> different names, so the problem with figuring which port is in_1 and
> which port is in_8 (I mean to which chain do they belong) should be that
> much easier to solve.

Yes, I did read Kai's post. And I did my own testing
with the 2.5.2 release. I think the latest features are in the git
repository.

Re-reading the posting at:

http://www.nabble.com/some-not-so-small-changes-to-JACK-support-td19643793.html

and the discussion leading up to that posting:

http://www.nabble.com/JACK-port-naming-td19354398.html

And then figuring out that I don't have the latest features
in my 2.5.2 version, I think am finally clear about JACK's
connections with Ecasound.

-i:jack,system (git version) is equivalent to
-i:jack_alsa (2.5.2)

Both get all the soundcard capture ports. The channel count
of the sound format specification (i.e. the '10' in
"-f:32,10,44100") tells Ecasound how many input ports to
create.

If I want compatibility with older Ecasound versions,
it makes sense to use jack_alsa, at least as a default
value.

Using the new -i:jack semantics, if I wanted to join the
"raw" signals from soundcard channels 3 and 4 into a single
stereo signal that could be sent to several destinations I
think I would have to use a loop device:

-a:1 -i:jack,system:capture_3
-a:2 -i:jack,system:capture_4 -chmove:1,2
-a:1,2 -o loop,222

I already do this by default. The output stereo signal
at loop,222 serves as input to another chain that
receives vol/pan/effects processing. I refer to
this processed signal as "cooked" (in contrast to "raw.)

I have another loop device that collects all the "cooked"
signals, delivering a "mixed" signal for file and soundcard
output.

Finally, I have a really clever routine (clever for me,
probably common in computer science) called eliminate_loops.

It looks at how many "customers" the cooked and mixed
signals have. If there is only one customer, the
corresponding loop device is eliminated, simplifying the
chain setup and reducing the latency.

Using -i:jack,system:capture_3 and capture_4, I will always
have to have the first loop device, even if only one
customer requires the signal.

Taking all the channels via -i:jack,system
or -i:jack_alsa isn't such a bad thing, certainly
not as default behavior. I can throw away the unneeded
channels. I don't think the processing cost is very high.

If I understand correctly, in the latest git Ecasound,
-i:jack,synth will automatically connect with synth,
so I won't need jack_auto in future. It just happened
that in my testing with 2.5.2, I still need to use
jack_auto, because -i:jack still needs to be manually
connected.

Regards,

Joel

P.S. I'm cc'ing this to the list as well, since
understanding these options is a hot topic at the moment.

> I'll have to skip back and reread those posts. I'll get back to you,
> probably tomorrow or later tonight.
> Kindest regards
> Julien

-- 
Joel Roth
------------------------------------------------------------------------------
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list