On Jan 10, 2011, at 3:11 PM, Roger Dannenberg wrote:
> 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.
Last time I did this, was, I think, with OSS, and that's how it worked.
> 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.
Hmmm. I think I understand. Can you define "shortly before"?
> 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).
Short of some crazy scheme with a "midi scheduling" thread and some
complex communication, or something like that, it sounds like events
need to be queued in the callback if they are to be synchronized, but
the danger of priority inversion is serious. While Linux is not a
concern of mine right now, it seems like there should be a "correct"
solution for this issue.
I will try to tweak the code such that events are queued in the
callback at the same time as the comparable audio is rendered. That
will be within the computed latency, which should be within any
reasonable definition of "shortly before".
bjorn
-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
_______________________________________________
media_api mailing list
[email protected]
http://lists.create.ucsb.edu/mailman/listinfo/media_api
