Re: [linux-audio-dev] [jack] frame_time of first frame in proces buffer?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] [jack] frame_time of first frame in proces buffer?
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Mon Jun 21 2004 - 16:09:12 EEST


>well, basically the idea is to write a simple drum softsynth.. a playing groun
>d for me to try out different synthesis approaches. for the start it will be a
> simple substractive synthesis..
>
>many softsynths just schedule the audio events for the start of the next perio
>d which introduces jitter and is really unacceptable especially with larger pe
>riod sizes..
>
>so one of the goals is to have a constant latency between incoming midi events
> and the corresponding sound output. the minimum latency for this is 1 period.
>. which is easy to see [at least i think so, i might be wrong]:
>
>let's assume a 1 sec period time. while period n is playing a midi event arriv
>es. with the help of jack_frames_since_cycle_start() i can find out how far we
> are into period n [let's say this is frame t]. since i want a constant latenc
>y of 1 period, i want to schedule the sound event for period n+1 at frame t. w
>hich is 1 sec later then the time the midi event arrived.

the fundamental problem with this approach is one that has affected me
adversely in ardour. jack_frames_since_cycle_start() is really only
safe to use in the JACK client thread. although you can call it
without adverse side effects from other threads, its implementation
means that you cannot rely on the answer. This is because there is no
way to interlock with the process cycle, so its impossible to know if
a cycle is in-progress, or has finished. I have made several
iterations on the design to try to cope with this, and what is there
now is reasonable. but its still possible to encounter the race
condition where another thread calls jack_frames_since_cycle_start()
just as the process cycle is starting up, and gets a silly answer as a
result.

if anyone has any ideas for how to resolve this race condition, please
let me or someone else working on JACK know about it. remember,
lock-free :) with h/w support, it would be easy, but the resolution
and reliability of many h/w "frame pointers" is not good, and in a
number of cases, is only updated at interrupt time making it no better
than JACK's existing system.

as it stands, i think the only correct solution to this issue at the
moment is to use the equivalent of UST. stamp the MIDI events with the
cycle timer (or gettimeofday() if you insist :), and queue them, from
the that handles MIDI I/O. then use a similar timestamp/measure in the
audio thread to decide when to "implement" them.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jun 21 2004 - 16:45:37 EEST