Re: Has nobody used CoreAudio Clock?
Re: Has nobody used CoreAudio Clock?
- Subject: Re: Has nobody used CoreAudio Clock?
- From: Brian Willoughby <email@hidden>
- Date: Tue, 03 May 2011 14:32:47 -0700
On May 3, 2011, at 13:38, Tom Jeffries wrote:
It's very simple- I have a MIDI sequencer that is playing data that
is updated in real time. I want to use a clock to check to see
what has been added, and then send the MIDI data out. I can
probably get reasonable accuracy using MIDIPackets, but it seems
more direct to take control of the playback by use of an accurate
clock.
Maybe that's not an option on OS X? I've done this on other
operating systems, I'll be a little surprised if OS X doesn't allow
it.
Your research has overlooked a very powerful feature of CoreMIDI: The
ability to queue outgoing events in advance of when they should be
transmitted, such that the system and/or hardware can handle the
timing more precisely than anything you could hope to do as a new OSX
programmer.
Basically, by insisting on handling the timing yourself, the accuracy
will only be as good as you can manage in your code. There are
options for hardware timing that would not be available to you unless
you use the CoreMIDI time stamping.
What is particularly important to take note of is that some MIDI
interfaces have their own clocking. CoreMIDI is able, via the proper
CoreMIDI driver, to synchronize with the MIDI hardware clock to
deliver MIDI data in advance of when it should be transmitted. Under
such conditions, the MIDI hardware holds on to this advance data and
then uses its own clock to control the timing of data transmission.
This is much more precise than anything you could do at the software
level, especially considering the latency of the link between the
main CPU and the actual MIDI hardware. Thus, even if you were an
advanced OSX kernel programmer, you would not have access to the same
degree of timing accuracy as the internals of the MIDI interface itself.
MIDI Interfaces such as the Emagic AMT-8 / Unitor 8 and various MOTU
interfaces with their proprietary MTS (MIDI Time Stamping) feature
support this hyper-accurate timing capability of CoreMIDI.
Unfortunately, USB-MIDI is an incredibly flawed design that was
created without the cooperation of the MIDI Manufacturers
Association. As a result, USB-MIDI has absolutely no control over
timing or latency. It's "good enough" for the price point, but not
necessarily good enough for music. This is a problem because most
people buy a generic USB-MIDI interface, probably because of the
price and because a custom driver is not needed.
You might think that your code doesn't have to be better than 99% of
the MIDI interfaces out there, but why go to great lengths to device
your own timing mechanisms when you can use CoreMIDI? As more people
learn about MIDI interfaces with advanced hardware timing, your
application will automatically take advantage of the improvements,
but without any special-cased code getting in the way of normal
operation with inferior USB-MIDI interfaces.
Then, the challenge becomes managing your recorded or generated MIDI
output stream such that you can deliver data slightly ahead of the
playback position. I'm not even sure what Apple recommends, but I'd
say that at least 10 ms in advance would probably be a good idea.
Your MIDI sequencer should thus be designed to always been looking
slightly ahead, so that CoreMIDI will always have a chance to
download the MIDI data stream to the MIDI interface in time for ultra-
precise timing.
Brian Willoughby
Sound Consulting
_______________________________________________
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