On 1/10/11 1:44 PM, Bjorn Roche wrote:
> Okay, below is my first stab.
Hi Bjorn,
That was fast! From your code, I think there is a misunderstanding
of how things work in PortMidi. I think your model is that a sequence of
events is loaded into PortMidi and then PortMidi writes this data out
over time according to the time it gets from the timeProc. This is a
reasonable assumption, but it's not how things work.
Instead, PortMidi does not have any internal store for future
events. Events pass through PortMidi to the Host API (e.g. coremidi)
immediately. The synchronization is achieved by translating timestamps
from timeProc coordinates to coremidi coordinates. This translation
happens at the time the midi message is sent, and the assumption is that
the clocks will not drift by any significant amount before the message
is actually sent. More precisely, what happens is that PortMidi computes
a difference between the system time and the timeProc time. This
difference is added to each timestamp to translate to system time, and
the message is sent on to CoreMidi. CoreMidi actually provides the
buffering if needed. Windows and Linux/ALSA work roughly the same way.
Therefore, MIDI messages should be sent incrementally and shortly
before their desired delivery time and not sent all in advance. That
way, any drift between timeProc and system time (reflected by changes in
their difference) will be applied to timestamps to support long-term
synchronization.
It should not matter to portmidi whether you send messages from the
main thread or the portaudio callback (but not both -- there's no mutual
exclusion). I would not be surprised, though, if ALSA midi sends called
malloc, which might create a possible priority inversion when sending
midi from the high-priority pa callback. (I don't know the internals of
ALSA -- maybe someone else can confirm or deny this concern).
-Roger
_______________________________________________
media_api mailing list
[email protected]
http://lists.create.ucsb.edu/mailman/listinfo/media_api
