Re: Multimedia timing on OS X
Re: Multimedia timing on OS X
- Subject: Re: Multimedia timing on OS X
- From: Ross Bencina <email@hidden>
- Date: Wed, 04 May 2011 18:39:50 +1000
Brian,
I agree with what you've said about CoreMIDI scheduling. I do not advocate
the use of the timer code I posted as the optimal way to schedule MIDI
events. However note that the question (and the subject line) is about
multimedia timers in general, not about CoreMIDI.
I posted the code because it is the best I have come up with based on
previous questions/discussions here and elsewhere and thought it would be of
interest and a good way to progress the conversation. I make no claims that
it is _the_ best way to do things, and of course, newcomers should excercise
due caution and seek to educate themselves of their options. The last thing
I would want would be for someone to take my word/code/ideas as gospel
truth.
One thing I would note about MIDI is that it is not a high performance
channel. A 3 byte MIDI message takes about 1ms to transmit, with
running-status you can do a bit better. Trying to send more than one message
at once is going to lead to significant jitter no matter what you do at the
driver level or with fancy hardware scheduling. Perhaps this is a good
reason to seek to remove all other sources of jitter to avoid adding even
more jitter.
Cheers
Ross
Brian Willoughby wrote:
On May 3, 2011, at 21:15, Ross Bencina wrote:
I'm pretty sure the CA Midi API allows you to schedule events into the
future. So that's probably the best option for MIDI. In theory at least
this allows the MIDI hardware to do the scheduling. I have no idea how
many hardware devices can actually do hardware scheduling. My current
MIDI Clock sync code just sends MIDI events in immediate mode (probably
not a good idea) from a polling timer thread.
I just run a high priority thread and use mach_wait_until() to sleep
until the next time.
In general I prefer using mach level APIs for this kind of thing.
Mach API generally are a good choice, they're my preference too, but in
this case it's all for naught. There is still a bottleneck between your
application calls and the physical MIDI port, including both fixed and
random latency. Often, this communication bottleneck includes USB, which
is not a high-performance channel. If you send MIDI events in immediate
mode, then there will be way more opportunity for unpredictable latency.
It may be very small, but it's unavoidable unless you schedule in
advance.
I'm not sure from your comments whether you have purposely chosen to use
immediate mode and Mach API out of a specific belief that this will
perform "better" or if you merely wanted to share your current
implementation to help out. I've been trying to explain that no matter
how much Mach-Fu you practice, you cannot beat the performance of
CoreMIDI because it is closer to the hardware. Short of writing your own
MIDI drivers, you're not going to be able to out-schedule CoreMIDI.
Rather than expend effort tuning your thread priority and Mach calls, I
suggest that you'll get much more mileage out of planning your sequencing
engine to schedule ever so slightly in advance.
A nice side-benefit of this approach is that you can relax the timing of
your code and just let CoreMIDI handle the heavy lifting.
You raise a good point about the fact that it is unknown how many
hardware devices there are that can actually handle hardware scheduling.
However, your given code example will simply fail to take advantage of
such hardware anywhere it is available. If your high-end customers see
your application performing to a lower standard than many other CoreMIDI
applications, that can't be good for your market share.
Brian Willoughby
Sound Consulting
P.S. I always appreciate when people are willing to share example code,
but if you're not even using the CoreMIDI as it was intended (scheduling
events in the near future) then I wonder if you're just sending newcomers
off on the wrong foot. I do not mean this as a personal criticism,
because even Apple released sample code that turns out to be incorrect.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden