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

Florian Schmidt mista.tapas at
Thu May 19 15:25:37 UTC 2005

On Thu, 19 May 2005 16:41:13 +0200
Alfons Adriaensen <fons.adriaensen at> wrote:

> On Thu, May 19, 2005 at 04:06:19PM +0200, Florian Schmidt 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.
> Call jack_frame_time() when you get the event, and add one period.
> Put the event in a queue, together with this timestamp.

Assuming though that the softsynth conforms to jack RT constraints it
needs to finish process() as fast as possible. Let's assume a very
leightweight synth which takes a time t_process which is much smaller
than the time available for a single period to process the data. 

To make it clear:

Interrupt N happens

softsynth's process() is called (we assume it's the only jack client, so
it's called right after the Interrupt happens). It finishes in t_process
seconds (<< t_(n+1) - t_n) Thus there's for all practical purposes still
t_(n+1) - t_n seconds left of period N. Any event that happens after t_n
+ t_process _cannot_ be scheduled for period N+1 as the processing for
period N+1 is already done.

Graphically (use fixed size font):

t ----->

|Irq N                       |Irq N+1                     |Irq N+2
||process_n()                ||process_n+1()              |
|    |process_n() done       |    |process_n+1() done     |
|               |keypress    |                            | 

The keypress cannot be scheduled for period N+1 (with constant delay) as
the process_n() (which prepared the buffer that will be audible during
period N+1) is already done. It can be put into the buffer by
process_n+1(). This buffer will be audible after Irq N+2

> 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).

This breaks afaics the rule of _reliably_ constant delay. OTOH i don't
qute grok it. Care to roll it out?


Palimm Palimm!

More information about the Linux-audio-dev mailing list