Minimum reasonable latency Was: Re: ZynAddSubFX was: Re: [linux-audio-dev] some new soundfiles on-line

Florian Schmidt mista.tapas at
Thu May 19 21:13:40 UTC 2005

On Thu, 19 May 2005 23:03:36 +0200
fons adriaensen <fons.adriaensen at> 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
latency :)

On Thu, 19 May 2005 16:06:19 +0200
Florian Schmidt <mista.tapas at> 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> 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 :)


Palimm Palimm!

More information about the Linux-audio-dev mailing list