Re: interapplication midi communication, cfmessageports, ques
Re: interapplication midi communication, cfmessageports, ques
- Subject: Re: interapplication midi communication, cfmessageports, ques
- From: Doug Wyatt <email@hidden>
- Date: Fri, 24 Feb 2006 11:01:03 -0800
On Feb 23, 2006, at 18:26, Alex Sheh wrote:
Hi All,
In my MIDI driver, there is a CFMessagePort’s run loop source added
to the current run loop. This MIDI driver is used to pass MIDI
data between 2 applications on a system, however lately I have been
seeing some issues that may be related to latency on this
communication channel – it also involves large amounts of MIDI data
are passed through over a long period of time.
Does it make sense to instead add my MIDI driver’s run loop source
to the realtime IO run loop? Although when I call
MIDIGetDriverIORunLoop( ) it returns NULL, is this normal?
That thread is initialized after drivers are loaded. So you're
probably calling MIDIGetDriverIORunLoop in your driver's constructor.
The run loop will exist when Start gets called.
Do CFMessagePorts seem reasonable for what I am doing
(interapplication, low latency)?
No. They allocate memory on every message, and thus are capable of
getting blocked by lower-priority threads. Furthermore there are
limits on the sizes of the queues of the underlying Mach ports.
Also, I’m not really clear as to how CFMessagePorts handle flow
control, in cases where there is a lot of MIDI data sent across
does this data start “piling up”? What about compared to
MIDIPortRefs?
The CoreMIDI app/server I/O mechanism is written to not take any
locks and generate as few and small cross-application messages as
possible, even when transferring large amounts of data. I'd suggest
using virtual MIDI sources and destinations to transfer data between
apps. Your driver of course can simply add its own sources and
destinations (and mark them private if it doesn't make sense for apps
other than your own to communicate with them). One way to do inter-
app communication would be to use such sources/destinations in your
driver to reflect messages between apps. This would be just as
efficient as creating MIDI virtual destinations or sources (and it's
also what the IAC driver does).
In your driver, a CFMessagePort -- on the main run loop -- is a fine
way to communicate non-realtime-critical information.
HTH,
Doug
--
Doug Wyatt
Core Audio, Apple
_______________________________________________
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