Re: Can MIDIPackets be modified after they are sent?
Re: Can MIDIPackets be modified after they are sent?
- Subject: Re: Can MIDIPackets be modified after they are sent?
- From: Brian Willoughby <email@hidden>
- Date: Mon, 06 Jun 2011 15:58:55 -0700
On Jun 6, 2011, at 15:06, Tom Jeffries wrote:
10 ms latency is not a problem, but jitter certainly is. The docs
for timers seem to imply that the actual message to the function
that plays the note may be delayed by 50 ms or more (the online
docs are down or I'd include a quote). Obviously that won't work.
Oops. You're right: the latency must be greater than the jitter in
order to cancel it out. If you're willing to work with 100 ms
latency then you should be able to use CoreMIDI for jitter-free
scheduling. Otherwise, it appears that NSTimer will not work for
you. Fortunately, OSX has other thread scheduling mechanisms available.
I tried using the CoreAudio Clock, but have not been able to find a
way that I can set a regular callback with it. That's why I set
things up using a series of MIDIPackets for the predetermined notes
with notes being generated in real time added in a separate set of
MIDIPackets to be played as quickly as possible.
I think you have the right idea by separating the sequenced notes
from the real-time events, but "as quickly as possible" will almost
certainly cause excessive jitter due to the realities of scheduling
in a multiprocessing environment. You need to give the CoreMIDI
scheduling enough time to work with, and thus should schedule at some
fixed point in the future. I'm not exactly sure how long that should
be, but it should certainly be greater than "immediate" (0
milliseconds).
Maybe I'm missing something obvious? Is there an accurate
millisecond clock? Did I miss something with CoreAudio Clock?
The CoreAudio clock is a reference, not a direct scheduling
mechanism. When you receive callbacks from CoreAudio or CoreMIDI,
all time stamps are CoreAudio clock derived, and thus share the same
accuracy. Similarly, when you schedule events, you also use
CoreAudio clock structures. But the challenge of waking up a
specific thread periodically in order to handle the scheduling is
something that must utilize another API. The slightly disappointing
thing is that most other timing API are less accurate than the
CoreAudio clock, but the good news is that if you design around a
reasonable latency, then you can convert between the CoreAudio clock
and whatever other host time you might be using for actual scheduling.
So long as CoreAudio and/or CoreMIDI have enough advance notice,
those API will be able to take your newly scheduled events and
execute them with CoreAudio clock precision. As I mentioned, the
CoreMIDI technology even allows this scheduling to be pushed all the
way out to the physical MIDI interface, if possible given the
specific drivers.
So long as you have the right thread-safe semaphores, you should be
able to create a dedicated thread for your near-real-time MIDI event
generation and then use the CoreAudio clock as a shared time base.
I'm not sure, but perhaps the CoreAudio thread priority might be
appropriate if you want your MIDI thread to wake up reliably. I
recall that this is referred to as fixed-priority thread scheduling,
because the priority is not diminished over time like the default
thread scheduling mechanisms.
In other words, you might still have some research ahead of you.
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