RE: interapplication midi communication, cfmessageports, ques
RE: interapplication midi communication, cfmessageports, ques
- Subject: RE: interapplication midi communication, cfmessageports, ques
- From: "Alex Sheh" <email@hidden>
- Date: Fri, 24 Feb 2006 16:15:02 -0800
- Thread-topic: interapplication midi communication, cfmessageports, ques
Thanks Doug, that is indeed very helpful. The fact that CFMessagePorts
allocate memory on every message in a less optimal manner does explain
the large memory footprint I'm seeing in the processes that are sending
and receiving a large number of MIDI messages on the CFMessagePorts.
The mach port queue limit may also be causing problems. I will try
using virtual destinations and sources as you suggest, and take
advantage of the lower bandwidth implementation. Thanks again!
- Alex
-----Original Message-----
From: Doug Wyatt [mailto:email@hidden]
Sent: Friday, February 24, 2006 11:01 AM
To: Alex Sheh
Cc: email@hidden
Subject: Re: interapplication midi communication, cfmessageports, ques
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