The backtrace shows MIDIServerMessagePort::ReceiveMessage() calling the internal implementation of MIDIPortDisconnectSource(). It only does this when some client calls MIDIPortDisconnectSource().
I have to suspect one of the daemons that some developers install to monitor their MIDI devices...
Doug
On Mar 26, 2008, at 9:47 , Daniel Mack wrote: Hi,
On Mar 27, 2008, at 12:18 AM, Doug Wyatt wrote:
A client application is calling MIDIPortDisconnectSource. It's not the MIDIServer, and not the CoreMIDI client framework.
As I said, the same thing happens with Echo.cpp from the SampleTools that ship with Xcode. Certainly, there is no MIDIPortDisconnectSource in that code, I just double checked that. So what else than the MIDIServer is in the chain that could be possibly blamed for that?
Daniel
On Mar 25, 2008, at 18:59 , Daniel Mack wrote:
Hi Doug,
On Mar 26, 2008, at 6:14 AM, Doug Wyatt wrote:
Please write a Radar including a backtrace from MyMIDIDriver::EnableSource(0)
This is the backtrace of the MIDIServer process when machine is put to sleep:
#0 MyMIDIDriver::EnableSource (this=0x30ced0, src="" enabled=0 '\0') at MyMIDIDriver:592
#1 0x000d6b3c in MIDIDriverEnableSource (self=0x30ced4, src="" enabled=0 '\0') at MIDIDriver.cpp:153
#2 0x0006829b in MIDISource::DisconnectPort ()
#3 0x00073460 in MIDIPortDisconnectSource ()
#4 0x00070d8e in MIDIServerMessagePort::ReceiveMessage ()
#5 0x927c3e21 in __CFMessagePortPerform ()
#6 0x927e5921 in CFRunLoopRunSpecific ()
#7 0x927e5d74 in CFRunLoopRun ()
#8 0x00076dc9 in MIDIServerRun ()
#9 0x00001fb1 in ?? ()
#10 0x00001f5e in ?? ()
Same things happens with /Developer/Examples/CoreAudio/MIDI/SampleTools/Echo.cpp, btw. So I think it's the MIDIServer's fault rather than the application's.
This is filed as #5820631 now.
Best regards,
Daniel
--
Doug Wyatt
Core Audio, Apple
--
Doug Wyatt
Core Audio, Apple
|