Re: [ecasound] Ecasound and jack (and chains)

Excerpts from Claude Heiland-Allen's message of 2010-08-17 03:20:52 +0200:
> On 16/08/10 22:48, Philipp wrote:
>
> [snip]
>
> > a) issue jack-list-connections
>
> [snip]
>
> > Another smaller, related issue, jack-connect requires:
> > jack-connect<outport> <inport>
>
> [snip]
>
> Hm, `jack_lsp -cp` lists connections with port properties (like input,
> output, etc) - maybe that's one option (but requires calling a command
> that might not be installed).

This should not be an issue unless the distribution packager goes crazy,
jack_lsp ships with the jack tarball.

> Or ecasound could be extended to add that
> information too, but that might break other clients unless it's
> optional. And even then, maybe it's not that useful as you know
> ecasound's input/output port names anyway?

Yes, I think I can get all necessary information from the Ecasound port
names, in which case this isn't necessary. I hope to implement it today.
However, the real solution would be Ecasound that is not disconnecting.

Disconnecting and auto-connecting is something audio production programs
usually don't do, simply because they can't know what the user wants to
do. Assumptions are more often wrong than right.

Audacity is one example that is heavily criticized for
auto-connecting to system_in/out when you hit play and disconnecting
when you hit stop.
This doesn't allow any routing, which is the main purpose of jack, and
this is why you won't find it as part of any elaborate setup.
Thankfully Ecasounds current behavior isn't that bad.

Usually multimedia players are the only programs where you want
auto-connect, they usually do something equivalent to
"ao-add jack,system" and this assumption is often wrong even for this
simple case (imagine you want some filter after the audio player or you
have a multichannel soundcard and output 1 and 2 do not correspond to a
pair of stereo speakers).

Ecasound reserves all resources when you connect the CS, and this seems
to be the root of the issue at hand.
It probably is necessary, but maybe it can happen at a different point.
For a take system to work without disconnecting jack it would need to
allow the change of aio while the CS is connected. Start and Stop could
reserve the resources. But I guess for other cases it would be necessary
to add/remove chains while the CS is connected. Anyway, this sounds like
rather severe design changes, and I don't know enough about Ecasound
internals, nor enough C++, to solve the issue.

> In any case, perhaps qjackctl's patchbay (or something similar is better
> designed for this very sort of thing?
>
> You can define regexp rules for connections and then when clients start
> up they are connected appropriately. I don't know if there is an easy
> way to clone the current state of the system into a set of patchbay
> rules, however - maybe someone who's used it for more than 10 minutes
> can tell you :)
>
> The patchbay file format seems to be XML text, so it should be possible
> for an external tool to take a snapshot of the current state into
> something that the qjackctl patchbay can understand.
>
> Some scenarious might want a qjackctl-style patchbay that runs without
> X, but I don't know if that exists.

I thought about this too. I would definitely prefer some script over
qjackctl. qjackctl may be installed on many systems, but I'd rather use
something that I could easily ship than requiring qjackctl. The X issue
might be a point too, but while I use tcp to talk to ecasound I haven't
tried nor thought a lot about actual network communication yet.

>
> Claude
> --
> http://claudiusmaximus.goto10.org

Ah, I think I have already seen/heard some of your pd videos,
nice stuff :)

-- 
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu
und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list