19 May
2005
19 May
'05
7:13 p.m.
On Thu, 19 May 2005 23:03:36 +0200
fons adriaensen <fons.adriaensen(a)skynet.be> wrote:
On Thu, May 19, 2005 at 05:59:25PM +0200, Florian
Schmidt wrote:
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(a)gmx.net> 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. 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(a)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..
[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/