[ecasound] Ecasound and jack (and chains)

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

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

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.

I realize that Ecasound wasn't designed with jack in mind,
but this is a serious flaw for any non-trivial usage with jack.

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

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