7 Nov
2010
7 Nov
'10
2:19 a.m.
On Sat, Nov 06, 2010 at 05:29:16PM -0400, Paul Davis wrote:
On Sat, Nov 6, 2010 at 5:13 PM, Joel Roth
<joelz(a)pobox.com> wrote:
Thanks for responding.
FWIW, I found a workaround for Nama. A drawback is that it
may interfere with clients expecting jack.plumbing to be
constantly available.
On startup:
- kill jack.plumbing if present
To setup engine:
- configure ecasound
- append our stuff to ~/.jack.plumbing
- start jack.plumbing
- sleep 0.5s
- kill jack.plumbing
On exit:
- remove our stuff from ~/.jack.plumbing
- restart jack.plumbing if originally present
Regards,
Joel
--
Joel Roth
Although ignorant about many things JACKish, I
would expect
that it's fair for a JACK client manage its ports as allowed
under JACK's API.
its entirely fair. what's not going to work is to have multiple
clients fighting to control the same set of connections.
I'd appreciate any suggestions, as I'm
about at the end
of rope (at least without plunging into jack.plumbing
and Ecasound's sources.)
your problem is in jack.plumbing. its really quite simple code, but
its not part of "official" JACK. put another way, jack,plumbing really
needs to know if the connections it wants to make are for active
clients, but there is (currently) no way to do this. most clients
become active immediately after port registration, but its not an
error for them not to do so. your setup is just exposing this weak
link in the chain, but its not clear where the "fix" should be.