On Thu, 19 May 2005 23:03:36 +0200 fons adriaensen <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.. [snip] > 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 :) Regards, Flo -- Palimm Palimm! http://affenbande.org/~tapas/
