Re: [ecasound] Problems changing transport position with JACK

> On Mon, 5 Jan 2009, Joel Roth wrote:
>
>> I'm reporting what I think is a bug when using Ecasound
>> 2.5.2 with JACK.
> [...]
>> What I notice is many seconds of delay from issuing a
>> playback-head repositioning command like "fw 40" until
>> playback resumes.
>
> this can be in fact normal. JACK transport changes are zero-delay actions
> in the sense that the system doesn't wait for clients to catch up with the
> new position, but instead JACK just keeps running forward from the new
> positions. An app like Ecasound, which reads samples from disk (and does
> not cache all samples in memory), cannot manage these seeks in real-time.
> In normal processing, meeting the real-time reqs is only possible as
> ecasound can buffer ahead, but this obviously won't work with seeks.
>
> For the user, the positive side is that you can do continous looping with
> a JACK system across multiple apps, but for the developer, this makes the
> implementation really hairy and may suprise some users as well.
>
> What Ecasound does is to implement is a "catch JACK's current position"
> algorithm that issues new read-ahead requests to all file objects until
> they eventually catch up. Depending on your disk i/o capacity and the number
> of files in your setup, this may take long (even multiple seconds).
>
> If you want to avoid this and make sure all samples from all clients are
> played from the new position, the JACK transport position needs to be
> changed with a different JACK API -> jack_transport_reposition() instead
> of .._position(). The former will wait until all "slow clients" have
> managed to seek to the new position before starting processing.
> Unfortunately ecasound does not support the reposition() variant, and in
> practise you need to stop processing, seek to a new position, and start
> again to get the same effect. Hmm, it seems that 'jack_transport' also
> does not support the reposition variant.
>
> Hmm, it might make sense to add jack-reposition support to interactive
> mode, though...

Is it possible that this is aggravated by using double buffering?

I know that if I do -z:db, that I get delays when doing "fw num" or "rw
num", but with -z:nodb, the repositioning happens immediately.

Rocco

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Mon Jan 19 16:15:01 2009