Re: [ecasound] jack-session (was: Re: RIFF header problem)

From: Joel Roth <joelz@email-addr-hidden>
Date: Thu Sep 16 2010 - 09:36:21 EEST

On Thu, Sep 16, 2010 at 08:15:48AM +0200, Philipp ??berbacher wrote:
> > 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?

Here's the thread in which Kai answers my questions on this
subject. It involves delays related to buffering, which
manifest when a position change occurs.
> 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.

What's amazing about writing software is our expectations
so frequently need to be revised. :-)

How does that saying go?

    In theory, theory and practice are the same but in
    practice they're different.



> --
> Philipp

Joel Roth
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
Ecasound-list mailing list
Received 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