>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
