Re: Blocked in MIDIClientCreate
Re: Blocked in MIDIClientCreate
- Subject: Re: Blocked in MIDIClientCreate
- From: Doug Wyatt <email@hidden>
- Date: Tue, 13 Dec 2005 14:24:17 -0800
On Dec 13, 2005, at 0:17, philippe wicker wrote:
On Dec 12, 2005, at 11:41 PM, Doug Wyatt wrote:
On Dec 12, 2005, at 7:53, philippe wicker wrote:
I did some tests using 2 MIDI devices available in the market.
The 1st one uses a vendor driver, the 2nd one relies on the
generic USB MIDI driver. I couldn't reproduce the blocking
behavior with these devices. So I'd tend to think that there's
something wrong with my device but I've no idea where to look at :(
What's happening when a MIDI client is killed with regard to the
actual device (e.g. any USB requests sent to it)?
What's happening when MIDIClientCreate is called with regard to
the actual device (e.g. any USB requests sent to it)?
What could cause the call to FindOrLaunchServer to be blocking?
Any idea?
Check your console log to see if there's a more specific error,
but it looks like MIDIServer is running but it is not responding
to the Mach messages from the client. The client-side framework
will wait up to 30 seconds before timing out and returning an error.
The console only displays the message "timeout waiting for
MIDIServer to start". But MIDIServer is running at that time , at
least that's what "top" tells me.
more below ...
So the question is, why is the MIDIServer hanging? It would appear
that your driver has something to do with that... let me know if
you have more questions.
The device is AudioStreaming and MIDIStreaming class compliant. The
USB controller is a Cypress FX2 chip. I didn't develop my own
driver but instead relies on the generic Mac OS X Audio and MIDI
USB drivers. As I wrote in my preceding posting, I tested the
application with a "vendor specific" driver device (Edirol UM-1S)
and a generic driver device (Evolution UC-16). Both are working
correctly (these 2 devices are MIDI only, mine is MIDI and Audio
though). This is why I believe that my device is doing something
wrong. But what?..... Maybe my device isn't responding correctly to
a USB request? I don't have a USB analyser to verify this
hypothesis...
I did an interesting additional test. I ran 2 test apps which both
open my device. If I kill one app, then the other still works, and
I can restart the killed one (MIDIServer is not hanging in that
case). If I kill both apps and restart one or both then the
MIDIServer is hanging. It appears that something special is
executed when the number of client reaches 0. Maybe this is a
herring?
What happens is that MIDIServer is launched on demand -- when the
first client makes a call into the CoreMIDI framework, the server
boots up. Subsequent clients find and connect to the original server
instance.
When client processes terminate (either by quitting, crashing, or
disposing all their MIDIClients), the server takes note, and if all
of the clients are gone, then the server exits.
So again, the question is, why is MIDIServer hanging? What you
describe gives us a good piece of additional information ... it
appears that when you launch / quit / relaunch your app, MIDIServer
may actually be hanging during the first shutdown process rather than
during startup.
A good place to start to debug this would be to use Shark or Sampler
to get a trace of what MIDIServer is doing when it is hung. We may or
may not get clues about what's happening in the USB stack from this;
I am concerned that you may indeed need to learn more about what's
happening on the USB bus. But a sample of the hung state would be a
good place to start.
Oh! -- you say your test apps "open your device." By this do you mean
that you are simply communicating with it via CoreMIDI (which is
fine), or are you actually using USB user client functions to open
the device and communicate with it directly, bypassing CoreMIDI? If
you're opening your own user client on the device, then I'm not sure
what the consequences of that would be, but it's very possible that
the class driver does not like having devices yanked away from it
like that, and could explain what you're seeing.
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