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

Excerpts from Joel Roth's message of 2010-08-17 04:40:33 +0200:
> 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!

That actually already worked with the tarball I sent some time ago :)
But yes, there has been some progress, even if the code hasn't changed
that much.

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

I think that would be possible, yes. jack_simple_client seemed to be an
obvious candidate, as all it does is copying its input to its output. It
is part of the example clients that ship with jack, so unless
distribution packagers go crazy, everyone should have it installed.
But I just noticed that it does autoconnect to system_in/out, which I
find a bit strange for an example client.

Thanks for that nice idea, I'll try it if my re-connect parsing stuff
fails. I guess I'll try it anyway. I already use it for my current
recording setup, where I route the sum bus of non-mixer to ecasound, but
I hadn't thought about dedicated jack client to work around the issue.

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

Same here. lua and C are said to extend each other nicely, but I don't
know C, so I have to go the pure lua 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.

But you also need to disconnect change the CS each time, right?
I wasn't sure whether the normal APIs suffer from the same limitation or
whether it's a net-eci thing.

> > 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 start to get used to it, I think I solved the data structure part this
morning and all that's left is a little bit parsing syntax and actually
writing the thing.

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

I have to disagree, it simply doesn't behave the way other jack clients
like DAWs do. I consider what I have to do as a major hack.

> It is worth looking into LASH/LADI, which provide tools
> to save/restore software and JACK connection state.

I'm quite sure they aren't designed to work around misbehaving clients
that disconnect all the time.
I haven't tried it, but with any of those I would expect the connection
to stay down until I re-load the state, which might have a whole lot of
other effects.

I'd love to use jack_session, but since it works with jack callbacks I'm
quite sure ecasound would need to support it and expose the controls
through NET-ECI.

> > 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' :-)

I didn't notice that :)
'lua fies' would translate to 'lua mean'.
It actually is a reverse acronym, the capitalization might help figuring
it out, and actually it should be: LuaF_IEs

It's a little puzzle :)

> cheers,
>
> Joel

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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list