• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Writing MIDI driver based on SampleUSBMIDI Driver code
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Writing MIDI driver based on SampleUSBMIDI Driver code


  • Subject: Re: Writing MIDI driver based on SampleUSBMIDI Driver code
  • From: Herbie Robinson <email@hidden>
  • Date: Fri, 16 Mar 2007 02:00:22 -0500

At 2:57 PM +0100 3/14/07, Nik Reiman wrote:
Hi Folks,
I've got a few issues with a MIDI driver that I'm developing, and so far, my research has turned up nothing. The MIDI driver is based on the SampleUSBMIDI driver project, and although it is working, but it has some strange behaviors that may be causing other problems with the device.


The first issue we are having is in the USBDevice class during the OpenAndConfigure() method. For some reason, the call to USBDeviceOpen() always returns kIOReturnExclusiveAccess from the device. As such, I've had to change this class to allow it to continue, as it normally should return upon receiving anything other than kIOReturnSuccess. Is there any particular reason that this call would return kIOReturnExclusiveAccess, even when it is not being used by any other application, and also after "fresh" reboots? Is it possible that there could be an issue with our firmware or hardware which would be causing this? The device also has a corresponding audio driver... is there any chance that this could cause this error?

There is a very good change that is causing the error. The general rule is one device, one client. The Apple guys will have to tell you how to get around it. It might have something to do with the configuration information you return or maybe you can't have separate drivers (i.e., maybe the audio driver needs to get the MIDI data and forward it to the MIDI driver).


While the device runs normally (despite the above return errors), I suspect that some of these "soft" errors could be causing more serious problems for some of our users. Also, I believe that this behavior is responsible for a related call to USBDeviceClose() failing during the driver destructor with a code of kIOReturnNotOpen. I think that this occurs due to SetConfiguration() not being called in USBDevice::OpenAndConfigure(), since the error code from USBDeviceOpen() is not IOReturnSuccess. Calling SetConfiguration() with anything other than kIOReturnSuccess crashes the driver, so I have left the error checking mechanisms in, and the call is never getting executed. Is there something in the SetConfiguration() method that "marks" the device as being open for the system so it could be cleanly closed later on?

SetConfiguration is almost certainly going to mess up the audio driver, isn't it?


Finally, the last question I have is in regards to semaphores being used in MIDI drivers. Presently, our driver has three mutexes that are used to protect read/write overlaps. While I think that these mutexes are correctly implemented and stable, I am still a bit uneasy about their presence in the driver. Generally speaking, is it safe to use semaphores in MIDI drivers?

Not in the real-time callbacks. This will result in priority inversions and cause poor timing performance (at best).


I have read that some hosts, such as Pro Tools, have many problems dealing with plugins using semaphores. Could a plugin accessing such a MIDI driver with semaphores also cause such problems?

Plug-ins don't live in the same address space as MIDI Drivers; so, they can't share semiphores.


Also, is there a preferred threading library that we should be using? At present, we are just using pthreads, but I've read that IOKit provides some of this functionality itself.

There are low level atomic queueing functions you should use. That or techniques that keep the real-time threads from needing any sort of concurrency control. You can count on the configuration stuff to all be single threaded by the MIDI Server.
--
-*****************************************
** http://www.curbside-recording.com/ **
******************************************
_______________________________________________
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
References: 
 >Writing MIDI driver based on SampleUSBMIDI Driver code (From: Nik Reiman <email@hidden>)

  • Prev by Date: Re: what would cause QTSetComponentProperty to fail with a kAudioUnitErr_InvalidPropertyValue err?
  • Next by Date: AAC and AudioConverter error : '!pkd'
  • Previous by thread: Writing MIDI driver based on SampleUSBMIDI Driver code
  • Next by thread: Thoughts/ideas on decompressing parts of an MP3 stream
  • Index(es):
    • Date
    • Thread