Re: Has nobody used CoreAudio Clock?
Re: Has nobody used CoreAudio Clock?
- Subject: Re: Has nobody used CoreAudio Clock?
- From: Tom Jeffries <email@hidden>
- Date: Tue, 03 May 2011 14:43:10 -0700
Brian, I assume you are talking about using MTC? Or does the MIDIPacket architecture have that level of accuracy? We also want to work with software synths. How is the clock accuracy when the synth is running on the computer rather than being external?
10 ms would be excellent.
Thanks, Tom
On Tue, May 3, 2011 at 2:32 PM, Brian Willoughby
<email@hidden> wrote:
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.
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