Re: Multimedia timing on OS X
Re: Multimedia timing on OS X
- Subject: Re: Multimedia timing on OS X
- From: Brian Willoughby <email@hidden>
- Date: Wed, 04 May 2011 00:09:12 -0700
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