On Sun, 20 Jun 2004 23:24:34 -0400 Paul Davis <paul(a)linuxaudiosystems.com> wrote: ok, maybe my question really is not well formed. Let me tell you about the problem i want to solve. maybe i am an the completely wrong track.. well, basically the idea is to write a simple drum softsynth.. a playing ground 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 period which introduces jitter and is really unacceptable especially with larger period 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 arrives. 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 latency of 1 period, i want to schedule the sound event for period n+1 at frame t. which is 1 sec later then the time the midi event arrived. so i put all incoming midi events into a ringbuffer with their corresponding jack_frames_since_cycle_start frame count. the jack process callback gets the midi events from the ringbuffer, iterates over the period it has to process and renders the sounds at the corresponding frame counts.. but i think there are subtle problems with that. they are hard to describe for me since i am not clear about some details of jacks workings. for example: if jack is playing period n, period n+1 gets rendered by the process callback. but at exactly which point in time does the process callback get called? is it possible at all to achieve contant latency of one period? i rather think it must be two periods, because all the midi events for the corresponding buffer must have arrived before starting to render it.. so to further investigate the issue i was thinking about which frame time[s] corresponds to the frames in the period passed to the process callback. by corresponds i mean: "at what frame time will the frames in that periods appear to play back. when i use jack_frame_time(), how do i know that the period i rendered at some point in time is played back now?" because with that knowledge i would just store the jack_frame_time of incoming midi events in the ringbuffer, and add one or two periods worth of frames to it. the process callback, knowing which [future] frame time it processes, could just happily render on until it meets the right frame time and start the rendering of the correspondding sound event.. so i wondered if jack does indeed have an internal frame counter [on which the jack_frame_time estimate is based] which could be passed somehow to the process callback to indicate which frame times it processes. maybe i'm on the completely wrong track though. what other solutions are there for the problem of constant latency with a jackified softsynth? i mean, i probably could get into some heave gettimeofday madness, etc, but i would rather use "jack time" instead of some other clock to schedule my audio events.. hope to have cleared out all clarities ;) florian schmidt P.S.: ah, to answer your question: i think i mean "free running, zero has no meaning frame time" -- Palimm Palimm!