Re: Blocked in MIDIClientCreate
Re: Blocked in MIDIClientCreate
- Subject: Re: Blocked in MIDIClientCreate
- From: philippe wicker <email@hidden>
- Date: Wed, 14 Dec 2005 18:50:33 +0100
On Dec 13, 2005, at 11:24 PM, Doug Wyatt wrote:
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.
When my test app is the only MIDI client, the MIDIServer exits when I
kill this test app. When the test app is relaunched. the MIDIServer
restarts and hangs when the app calls MIDIClientCreate.
When my test app is not the only MIDI client (eg when MIDI Monitor is
running), the MIDIServer never exits and my test app never blocks in
MIDIClientCreate.
Don't know if this can shed some light, but the hang occurs **ONLY**
when the USB device has sent a MIDI message. Otherwise everything is
fine.
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.
I've tried to use Sampler (recording IPC and Locking calls), but I
don't know how to attach the MIDIServer when it is relaunched. If I
attach it when I'm hung in MIDIClientCreate then nothing is recorded
(no activity of MIDIServer?).
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.
I use only CoreMIDI APIs.
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