Re: interapplication midi communication, cfmessageports, ques
Re: interapplication midi communication, cfmessageports, ques
- Subject: Re: interapplication midi communication, cfmessageports, ques
- From: Wayne Anderson <email@hidden>
- Date: Fri, 24 Feb 2006 13:26:16 -0700
Hi All,
On a related note. What is the preferred way to get a signal into
the main thread run loop from another thread within an application?
Say for example, I want to get derive a time stamp from the CA
render thread and signal the app thread to update some widget.
From the previous discourse, it looks like using CFMessagePorts
could be risky. Does CFMessagePortSendRequest always allocate memory
even when the data param is NULL?
Thanks,
Wayne Anderson
___________________________________
Wayne Anderson
Red Rock Software, Inc.
On Feb 24, 2006, at 12:01 PM, Doug Wyatt wrote:
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.
_______________________________________________
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