19 May
2005
19 May
'05
1:25 p.m.
On Thu, 19 May 2005 16:41:13 +0200
Alfons Adriaensen <fons.adriaensen(a)alcatel.be> wrote:
On Thu, May 19, 2005 at 04:06:19PM +0200, Florian
Schmidt wrote:
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
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. 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/