[...] > Well, i guess i didnt make myself clear enough. > Technically, when you use some count/clock/tick based method > for doing things, there is a certain hardware that generates such > things. > How are you sure that you will be able to generate those reliably > within > the OS? The only way is generating them in realtime, and prequeuing > would be impossible.
The MIDI API just allows scheduling MIDI for transmission at a certain future UST. Either scheduling is done (partly) in hardware or in a process that schedules the messages (using POSIX clock_nanosleep() or a similar function). I'm thinking instead of the current sequencer API there is a user space 'sequencer' that handles merging and accepts clients to send it either scheduled or immediate messages (queued) and have a 'driver' be a combination of a kernel driver (ALSA rawmidi or device specific) and a 'driver' process that registers queues with the user-space sequencer. I'm working on this, but it is not that easy since merging MIDI streams is non-trivial and I want to be able to have hardware do the scheduling if it supports it and this means events can only be queued in timed order. > It happens the same when the OS generates > midi clocks, if the load affects wathever is timing internally, > all your queue gets screwed. This has its uses i guess anyway. [...] > What i mean is the audio callback prooviding the UST time. I mean it's > not necesary > since you can compute the delay in time from ust and the audio buffer > size, but OK, I'm not sure what you mean here, but as I said earlier, I think the audio API should provide a MSC for every buffer in a callback and a UST for every input buffer corresponding to the end of that buffer. Perhaps better: a callback could provide a single UST/MSC pair on every callback where the MSC is higher than the highest MSC in any input buffer. > I am _definitively_ in favor of this. Alsa should proovide this, and > JACK _must_ do it, > so clients can syncronize properly. I wonder if Paul can be convinced to add UST timestamping to JACK. He seems to be agreeing with me lately so things are looking good :) > > I disagree. I'd rather have a small extra latency than jitter. > > We're taling about something WAY beyond human-hearable latency. > Say you send the event, it will probably reach in nanoseconds if > things > go right, or useconds if things go not so right. The event would > need to delay like, 5 milliseconds for you to notice any jitter. > And this will _never_ happen. Absolutely *never*. Since the MIDI API I was talking about timestamps the messages at the start of the message on the wire it will always arrive at the application between 1-2 msec late. To avoid possible jitter at audio buffer bounderies messages should arrive early instead of late and thus some extra latency should be added to the MIDI messages' UST. A 2 msec jitter is irritating, an extra 1-2 msec delay isn't. Note that at the moment there aren't any softsynths on any platform that I know of that can do this, and many have audio buffer size MIDI message jitter on output. ( http://www.rme-audio.de/english/techinfo/lola/latec.htm ). > Well, all in all we're both talking about the same. ALSA and JACK > should proovide > access to some timer similar to UST. Now the real problem is the > implementation. > How to do this? Not all architectures proovide a secondary clock for > such things, > and on X86 I cant think of something other than the pentium cycle > counter. As long as POSIX clocks are available from both user- and kernel-space and we all agree that CLOCK_MONOTONIC is UST for Linux, that'll do. ALSA drivers could then use CLOCK_MONOTONIC to timestamp buffers. How CLOCK_MONOTONIC is implemented is not that important, It'll probably have to be the firm- or hard- timers patch for Linux. --martijn ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
