Minimum reasonable latency Was: Re: ZynAddSubFX was: Re: [linux-audio-dev] some new soundfiles on-line
mista.tapas at gmx.net
Thu May 19 21:13:40 UTC 2005
On Thu, 19 May 2005 23:03:36 +0200
fons adriaensen <fons.adriaensen at skynet.be> wrote:
> On Thu, May 19, 2005 at 05:59:25PM +0200, Florian Schmidt wrote:
> > > You shouldn't check for events int jack_process(), but in a separate
> > > thread, linked to jack_process() using a lock-free circular buffer for
> > > the [event+timestamp] data.
> > Of course. I assumed that you assumed that i know this :) But this is
> > not the problem. I still insist: To get constant latency you have to
> > take 2 periods worth latency into account.
> The scheme I described will give you exactly 2 periods latency.
Yeah and i asked for a scheme which would give us 1 period constant
On Thu, 19 May 2005 16:06:19 +0200
Florian Schmidt <mista.tapas at gmx.net> wrote:
> I don't know of any _reliable_ constant delay (jitter free) way to
> schedule events happening during period N for playback during period
> N+1. If anyone does, please enlighten me.
On Thu, 19 May 2005 16:41:13 +0200
Alfons Adriaensen <fons.adriaensen at alcatel.be> wrote:
> Call jack_frame_time() when you get the event, and add one period.
> Put the event in a queue, together with this timestamp.
> In your jack_process() : set t0 = jack_last_frame_time(), then handle
> all events that fall before t0 + period. The sample index for the
> event is its timestamp - t0 (or O if this happens to be negative).
So i was mighty confused. I was wondering: "how in the world is he gonna
achieve 1 period worth of constant latency with this? :) So i started to
elaborate on why a scheme for constant latency really gives you 2
periods worth of constant latency..
> The latency of two periods is composed of one period from the hardware,and
> one period we added to the timestamp of the event.
This is of course, worded better :)
More information about the Linux-audio-dev