[...] > UST can be used for timestamping, but thats sort of useless, since the > timestamps need to reflect audio time (see below).
I\'d like to have both a frame count (MSC) and a corresponding system time (UST) for each buffer (the first frame). That way I can predict when (UST) a certain performance time (MSC) will occur and use this to schedule MIDI, i.e. through a MIDI API also supporting UST. > UST cannot (on my > understanding) be used for scheduling. That\'s correct. The application doesn\'t need to. But in the case of a MIDI API that accepts UST stamped messages and transmits them at the correct time, the implementation might use scheduling on UST directly or it might create a mapping between UST and the system clock used for scheduling. With UST implemented as CLOCK_MONOTONIC the implementation can actually schedule on that. > >But JACK doesn\\\'t provide timestamps, or does it? > > it doesn\'t timestamp buffers, because i firmly believe that to be an > incorrect design for streamed data. Why is this an incorrect design? I don\'t understand. > however, it does provide (if a > client volunteers to do this) a time base. see jack/transport.h. the > API is not in the main header because we don\'t want to frighten > users. most applications don\'t need this stuff at all. I see it is possible to get the current frame position? Is it not possible to get the position of the first frame on every callback? [...] > CLOCK_MONOTONIC doesn\'t change the scheduling resolution of the > kernel. its not useful, therefore, in helping with this problem. Not useful right now. CLOCK_MONOTONIC scheduling resolution will get better I hope. For MIDI output this resolution is of importance whether you use a UST/MSC approach or not. Is the clock resolution for Linux in clock_gettime() also 10ms right now? What is the correct clock to use for timestamping if not CLOCK_MONOTONIC? > what > you need is an API that says \"do this at time T\", and have some > good expectation that the jitter on \"T\" is very very small (right now, > its generally huge). I agree. But the question is, in what timebase should time T be given if not UST? > the \"firm timers\" patch helps with this immensely (and before it, the > KURT patches did the same thing). they don\'t involve a change to libc. No, and I\'ve tried firm timers patch and it performs great. But it doesn\'t add CLOCK_MONOTONIC IIRC, and thus using CLOCK_REALTIME you still run the risk of having the clock adjusted. --martijn Powered by ASHosting
