Re: Terrible MIDI timing
Re: Terrible MIDI timing
- Subject: Re: Terrible MIDI timing
- From: Kurt Revis <email@hidden>
- Date: Sun, 18 May 2003 22:05:38 -0700
On Sunday, May 18, 2003, at 03:42 PM, Jeremy Jurksztowicz wrote:
All my code does is send MIDIRawData
messages to my virtual endpoint MIDIReadProc, which calls a step
function, which increments a step variable,
sees if any "sound events" are at that step, and triggers them.
However I found that the timing was very odd. At what
appears to be random increments, the timing will go off.
It sounds like you are saying that whatever you're doing in the
MIDIReadProc sounds wrong (the timing is off). So let's back up a
level from there. Have you established that the MIDIReadProc is called
at the wrong intervals? You might log the value of
AudioGetCurrentHostTime() when your MIDIReadProc is called, and see
what it looks like. You could also compare that with the timestamps of
the MIDI events you are given... they should be reasonably close (don't
expect them to be perfectly identical).
Also: you need to note that the MIDIReadProc is called in a separate
thread (a high-prority thread that CoreMIDI creates for you). If you
try to do things in this thread that could contend with things
happening in other threads -- like allocating memory, locking a lock,
or updating UI -- you are likely to run into priority inversion, where
your high-priority thread is effectively reduced to the priority of
some other thread (probably your main thread). The results of this
could sound like "bad timing".
So of course I assumed that I was doing too much In the callback
procedure,
I'm not sure that's true (maybe, maybe not). It's not necessarily a
question of how much processing you're doing, as the nature of that
work, and whether it might block the thread for a long period of time.
and replaced all my code with a simple SysBeep(30).
This doesn't sound like a very reliable debugging method to me. As far
as I know SysBeep calls down to the Carbon sound manager, which itself
calls down to CoreAudio, and does a bunch of work in a variety of
separate threads (maybe even file I/O to read the alert sound file, for
all I know). I would be really surprised if all of this stuff could
work without causing some contention with the main thread (or at least,
some other thread). It's not nearly as simple as you think.
Here's a lot more lightweight method: before you start, allocate a big
array of timestamps (say 1000 of them). Each time your MIDIReadProc is
called, save the current time into the next free space in the array.
When you hit the end, output the array (perhaps printf to the screen or
to a file), reset your index back to the front of the array, and
continue. This way, the process of taking the timestamp doesn't take
much time and cannot block. (Outputting the timestamps will probably
block, but that doesn't happen very often, and won't affect the
accuracy of the timestamps you've already taken.)
Hope this helps and is not too elementary.
--
Kurt Revis
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.