Excerpts from Joel Roth's message of 2010-09-16 03:54:13 +0200:
> On Wed, Sep 15, 2010 at 09:30:32PM +0200, Philipp ??berbacher wrote:
> > Excerpts from Joel Roth's message of 2010-09-15 21:09:29 +0200:
> > > On Wed, Sep 15, 2010 at 01:34:35PM +0200, Philipp ??berbacher wrote:
> > > > Oh, I talked to Torben Hohn, the head behind jack-session, a few weeks
> > > > ago. The automatic shutdown of the engine do get in the way of
> > > > jack-session and he said the problem could be solved by decoupling the
> > > > jack part, or something, but apparently it's not trivial. Well, there's
> > > > hope that he'll do it and add jack-session support sometime. This would
> > > > likely happen in a way that ecasound handles the low-level stuff and
> > > > exposes what's necessary for frontends to handle the rest.
> > >
> > > Thanks for the update. Could you explain what you mean
> > > by 'automatic shutdown' and how it influences
> > > jack-session?
> >
> > Changes to aio of a connected CS and possibly others require the CS to
> > be disconnected, which in turn means the engine gets shut down and the
> > jack connections are lost.
> >
> > It's not the purpose of jack-session to reconnect the client in such a
> > case. Jack connections are supposed to be under the users direct
> > control, using a connection manager of sorts. Jack-sessions also assumes
> > this is the case. It's not designed to make non-persistent connections
> > 'magically' persistent. Therefor to make ecasound work with jack-session
> > ecasound must first behave properly, which means it needs persistent
> > jack connections.
>
> > Sorry if that's a little long and complicated :)
>
> Neither. Now I understand!
>
> You'd mentioned before that this behavior bothers you.
>
> I wonder how it could be resolved... Probably Kai is in
> a better position to imagine that than I am. :-)
Or even better, maybe Kai and Torben can stick their heads together for
a few minutes.
> One of Nama's options is to connect a list of JACK
> ports to a track input. Looking at the source
> code, I see that I do this *after* 'engine-launch'
> using jack_connect.
>
> cs-load
> cs-connect
> cs-engine-launch
>
> # connect_jack_ports
>
> Does your code explicitly launch the engine?
Yes, my old code (in the master branch) explicitly sends
'engine-launch', waits briefly, connects the ports and sends 'start'.
> You commented about disliking needing a "settling time"
> before the engine set up the JACK ports. I think that it's
> legitimate to recognize such delays.
The above mentioned wait does exactly that, it tries to avoid connection
attempts before the jack client is ready. The problem with it is that
it's just a guess. Master has 1/10 of a second there and it seems to
work. Maybe it won't on another machine or with just a different load.
> When Nama changes Ecasound's playback position under JACK,
> it's necessary to:
>
> 1. stop the transport
> 2. change the playback position
> 3. allow 0.1s for the system to "settle"
> 4. start the transport
I didn't deal with this part yet, why does it need to "settle"?
Th ecasound-iam manpage mentions a few position related commands that
won't work with a connected CS, but all of those control ai or ao
independently, so changing the position of the whole CS should work.
In my old code, when the user issues the stop command, I issue "stop",
"cs-setpos 0s" and it doesn't disconnect the jack ports, hence the CS
stays connected. Does it need to "settle" for another reason? Why do
you need the stop/start?
There's no arbitrary setting of positions in my code yet, and there
are no plans for it yet, so I don't know the details.
> That's compared with the situation under ALSA:
>
> 1. change the playback position
>
> If a one-line sleep can solve your problems, I think you
> should be happy!
>
> Joel
I'd expect it to work the same with jack.
-- Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Ecasound-list mailing list Ecasound-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecasound-listReceived on Thu Sep 16 12:15:01 2010
This archive was generated by hypermail 2.1.8 : Thu Sep 16 2010 - 12:15:01 EEST