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

From: Florian Schmidt <mista.tapas@email-addr-hidden>
Date: Thu May 19 2005 - 18:25:37 EEST

On Thu, 19 May 2005 16:41:13 +0200
Alfons Adriaensen <fons.adriaensen@email-addr-hidden> 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?

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/
Received on Thu May 19 20:15:09 2005

This archive was generated by hypermail 2.1.8 : Thu May 19 2005 - 20:15:10 EEST