>> >Why not have a seperate API/daemon for MIDI and >> >have it and JACK both use the same UST timestamps? >> >> you can\'t use any timestamp unless its derived from the clock master, >> which UST by definition almost never is. the clock on your PC doesn\'t >> run in sync with an audio interface, and will lead to jitter and drift >> if used for general timing. > >The mapping between UST and audio time (frames) is continuously updated. >There is no need for the UST to be the master clock. If JACK would
UST = Unadjusted System Time I haven't seen any implementations of UST where you could specify a different source of the clock tick than the system clock/cycle timer. >audio by scheduling it on UST. An application doing JACK audio output >and MIDI output would most likely estimate the UST for the output buffer >using the UST of the input buffer and schedule MIDI messages for that >buffer in the callback also. So this then looks much like your proposal. >But there is also still the ability to use send MIDI messages for >immediate transmission. Well, thats actually what we have in JACK already, if the client uses the ALSA sequencer in another (non-JACK) thread. its precisely the design i have in my head for Ardour, for example. >Using UST would also enable syncing to video or some other media >stream without it all residing in the same API. Something has to connect the UST to the applications, and I have not seen anything in the definition of UST that would put UST in user space. --p
