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

On Mon, Aug 16, 2010 at 11:48:36PM +0200, Philipp wrote:
> Hi.
> I did some more experiments and well, ran into some issues with regards
> to jack. The main issue is that ecasound disconnects from jack in a
> number of cases.
>
> So far my core feature is a 'takes' system. It should be possible to
> start another take with a single keypress. At the moment it's two, but
> that doesn't matter.

Hello Philip,

Glad to see you're making progress!

> To implement a takes feature I need multiple files.
> To switch between files I need to disconnect the CS, which means I need
> to tear down the jack connection.
> Even if all I want to do is to play back the file I just recorded, I
> need to switch CS, which means tearing down the jack connections.
> Why I need to change CS is explained later.
>
> Tearing down jack connections is bad. Something like ao-add jack,system
> only covers the most trivial cases. In lots and lots of cases you use a
> connection manager of some sort to make connection, like qjackctl,
> patchage or whatever. There might be ten connections from the ecasound
> jack out to ten different apps, and they'd all be gone and would need to
> be re-established. I hope this makes clear why the need to tear down
> jack connections is a serious shortcoming.

I haven't played that much with JACK's permutations
and combinations, but am wondering if you
could use an intermediate JACK node:

Ecasound ---> intermediate --> several JACK clients

Then you would only have to replace one connection,
Ecasound -> intermediate.
 
> -Why I need to change CS, even without takes.-
> I thought about using a single CS and multiple Chains instead, but
> I don't see a way to do it. Take a simple case: You record to a file and
> want to listen to what you recorded. For that you'd need two chains, one
> from say jack to file, the other from file to jack.
> The idea was to mute the playback chain and record using the record
> chain. So far this works, no issue. When you want to listen to the
> recording, then you mute the recording chain and unmute the playback
> chain. This works exactly once, because while you listen through the
> playback chain, the record chain overwrites the file with zero-samples.
>
>
> -My "solution"-
> It's more like a hack-around than anything else. I haven't implemented
> it yet, because I wonder whether there's a nicer solution to the problem
> that escaped me.
> I plan to, before any command that causes a disconnect:
> a) issue jack-list-connections
> b) parse the input, filter out the connections to and from ecasound and
> store the information
> c) issue the problematic command
> d) issue a command that will restore the connections based on the
> previously stored connection information
>
> I consider this a rather ugly solution, and parsing the
> jack-list-connections output is likely error-prone. Hence I'd like to
> avoid that.

I know I've dealt with this problem, at least in parsing
the output of jack_lsp. There is a C-language
interface to get this data, however with my missing C-fu,
I've chosen to go the parsing route.

JACK client connection _can_ be part of the Ecasound chain setup.

Nama allows each track to route audio to external
JACK clients via aux send or as inserts.

> Another smaller, related issue, jack-connect requires:
> jack-connect <outport> <inport>
> with:
> jack-connect <inport> <outport>
> it will fail. It shouldn't matter in which order you specify it, as long
> as it's one input and one output port. It's just a detail that makes the
> above mentioned implementation a little bit harder, since I need to
> parse and store this information as well.
 
Once you get used to it, you'll find parsing, storing and
using the stored data to be no big deal.
 
> I realize that Ecasound wasn't designed with jack in mind,
> but this is a serious flaw for any non-trivial usage with jack.

Only for apps/scripts that refuse to manage data for themselves.

It is worth looking into LASH/LADI, which provide tools
to save/restore software and JACK connection state.
 
 
> On a brighter note, I made a little progress with my frontend, the tcp
> code works without corner cases and without timeout (using the length
> information provided in the message from ecasound).
> Today I finally put it into git, and the guys at tuxfamily are so kind
> to host it.
>
> Gitweb can be found here:
> http://git.tuxfamily.org/?p=gitroot/seifaul/seifaul.git
> And it can be cloned with a simple:
> git clone git://git.tuxfamily.org/gitroot/seifaul/seifaul.git

which backward spells 'luafies' :-)
 
cheers,

Joel

> You might notice the name change. I figured the name 'lecka' might be
> better suited to ecasound lua bindings, if I ever manage to write those.
>
> It's not yet out of the proof of concept stage, it has some nasty
> hardcoded paths and stuff.
> Next bigger items on the agenda is the connection issue, then a simple
> GUI (probably GTK+), and then I might start working towards making it
> more generic and hence useful to others.
>
> I appreciate any input.
>
> Regards,
> --
> 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@email-addr-hidden
> https://lists.sourceforge.net/lists/listinfo/ecasound-list

-- 
Joel Roth
------------------------------------------------------------------------------
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