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: Tue, 28 Feb 2006 12:57:48 -0800
- Thread-topic: interapplication midi communication, cfmessageports, ques
Hi Doug,
Thanks for your help thus far. I have a few more questions regarding
MIDI port implementation choices. More details on my overall
architecture - myMIDIDriver is sitting between a thirdPartyApp and myApp
facilitating inter-app MIDI communication. To send MIDI data from myApp
to thirdPartyApp, I call MIDIReceived( ) from myApp to send MIDI to
myMIDIDriver's myPort (thirdPartyApp is configured to listen to myPort).
To send MIDI data from thirdPartyApp to myApp, I relay the MIDI from
myMIDIDriver to myApp (thirdPartyApp is configured to send to myPort).
Also, I can have up to 8 instances of myApp running at the same time,
each with 4 ports, and 32 ports on myMIDIDriver, with 1 to 1 port
correspondence between myApp's ports and myMIDIDriver's ports.
To relay the MIDI Data I can either create a virtual source in
myMIDIDriver and connect an input port in myApp, or I can create a
virtual destination in myApp and connect an output port in myMIDIDriver.
Is either of these more efficient? Does multiple myApps pose a problem
for the myApp virtual destination case (they would, however, haver
different destination names)? I would think that for the myMIDIDriver
virtual source case, it would make more sense to have 4 input ports
listening to 4 separate virtual sources, rather than 1 input port
listening to 4 virtual sources - since there would be 4 callback threads
versus 1 (more efficient, though I still need to verify that there
aren't any synchronization issues), is this the case?
Thanks for your time.
- Alex
-----Original Message-----
From: coreaudio-api-bounces+asheh=email@hidden
[mailto:coreaudio-api-bounces+asheh=email@hidden] On
Behalf Of Alex Sheh
Sent: Friday, February 24, 2006 4:15 PM
To: Doug Wyatt
Cc: email@hidden
Subject: RE: 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:
m
This email sent to email@hidden
_______________________________________________
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