• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Can MIDIPackets be modified after they are sent?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can MIDIPackets be modified after they are sent?


  • Subject: Re: Can MIDIPackets be modified after they are sent?
  • From: Ross Bencina <email@hidden>
  • Date: Tue, 07 Jun 2011 11:42:01 +1000

Hi Tom

Maybe I'm missing something obvious? Is there an accurate millisecond clock?

As far as I know there's not a high-level API like Windows' multimedia timers' timeSetEvent().


It's worth searching the mailing list archives, this question has been asked before.

I posted some crappy code and links last month in a thread "Subject: Multimedia timing on OSX":
http://lists.apple.com/archives/coreaudio-api/2011/May/msg00035.html
Probably the links in that post are more useful than the code.


The basis of this approach is to use a high priority thread, use mach_absolute_time() and mach_wait_until() to get as close to the desired time as possible. I havn't done extensive measurements but from what I've read elsewhere, this approach gives precision well under 100 microseconds.

Note that I don't recommend using that code as-is. The ttcpolicy is hardwired with crazy magic numbers, and the timer period accumulation is done in doubles insead of int64 for some odd reason.

The post linked above also hints at the possibility of using a normal high-priority thread instead of a real-time thread. I don't think that's even a vaguely good idea any more. From what I've seen THREAD_TIME_CONSTRAINT_POLICY is essential. I've recently tried using FIFO priority, and it gets messed up quite a bit when launching apps or other high-load operations. Understanding the THREAD_TIME_CONSTRAINT_POLICY parameters requires some research (possibly back to pre-Apple CMU documentation) -- don't take the hardwired time constraint parameters in that code I posted for granted, looking at them now I don't think they're correct. I'm in the process of fixing this for my own code. In any case, if you're going to use THREAD_TIME_CONSTRAINT_POLICY you need to learn how it works, and how to use it.

Standard disclaimer: this kind of thing should _not_ be used directly for high-accuracy MIDI scheduling. CoreMidi provides it's own scheduler for that.

Ross.

_______________________________________________
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


References: 
 >Re: Can MIDIPackets be modified after they are sent? (From: andre <email@hidden>)
 >Re: Can MIDIPackets be modified after they are sent? (From: Tom Jeffries <email@hidden>)
 >Re: Can MIDIPackets be modified after they are sent? (From: Brian Willoughby <email@hidden>)
 >Re: Can MIDIPackets be modified after they are sent? (From: Tom Jeffries <email@hidden>)

  • Prev by Date: Re: Can MIDIPackets be modified after they are sent?
  • Next by Date: Re: Problems with a Low Pass Filter process
  • Previous by thread: Re: Can MIDIPackets be modified after they are sent?
  • Next by thread: Re: Create MIDI device programmaticly without a MIDIDriver bundle
  • Index(es):
    • Date
    • Thread