Welcome back, Kai,
On Tue, Jan 13, 2009 at 12:09:49AM +0200, Kai Vehmanen wrote:
> 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.
Great! Stop, set position, delay, start works fine for me.
I find a delay of 0.1 seconds for allowing a seek
is plenty, even with multiple large files on an old USB
drive.
Joel
-- Joel Roth ------------------------------------------------------------------------------ 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-listReceived on Tue Jan 13 08:15:01 2009
This archive was generated by hypermail 2.1.8 : Tue Jan 13 2009 - 08:15:01 EET