Author Topic: USB Audio Jack Information Reporting  (Read 18371 times)

fwdev7

  • Member
  • ***
  • Posts: 3
USB Audio Jack Information Reporting
« on: November 08, 2010, 01:22:52 pm »
Hello,

First off, I was surprised to find that the USB-IF developer's forum went missing, but I'm glad I found this forum.

Anyway, we are developing a USB audio device that has a 3.5mm audio jack with a detection switch for jack sensing and I am wondering if there is a way to report the jack status to the host?

I searched through the audio 1.0 and 2.0 specification and didn't find anything related to the audio jack. Currently we have our device implemented as a speaker, I've also tried lineout but then we don't get the volume controls (at least in win XP)

I've also looked through the HID Usage tables, but didn't find anything there either.

What we want to do is prevent windows from automatically switching the sound output to our device when there is nothing in our audio jack. Currently we have a hack that switches the sampling rate in our audio format descriptor from 0Hz (nothing in jack) to 48kHz (something in jack) and then disconnecting our D+/D- lines to force a re-enumeration. We have found that does what we want on WinXP but we have found that on Win7 if we connect the first time (never plugged in before, shows driver installing bubble) without anything in our audio jack (and hence using the 0Hz descriptor), subsequent connections even with something in our jack will not allow us to play audio, as if Win7 has cached our old format descriptor and isn't listening to our new descriptor. The workaround we have for now is to make sure something is in our jack before connecting to Win7, or if the driver is already installed, uninstalling the driver (from device manager) and plugging in our device with something in the jack.

We want to avoid using 2 PIDs to separate the 2 cases since we have software that only recognizes one PID and stores settings based on it (e.g. if we had 2 PIDs then they would have different stored settings, confusing the user since there is only 1 physical device, e.g. "sometimes my device has this setting even though I set it to something else last time").

So we are hoping that if we can somehow report the jack status, we wouldn't need to do any hacky workarounds (like the one we have now).

Any help or advice would be appreciated, thanks!

Guido Koerber

  • Frequent Contributor
  • ****
  • Posts: 72
Re: USB Audio Jack Information Reporting
« Reply #1 on: November 10, 2010, 05:40:20 pm »
I am not very familiar wut USB audio, so no idea if there is anything available. But if you just want to signal you status to some piece of software you can go for generic HID (subclass = 0), this prevents the HID class from loading a driver for that function and you are then able to access the data from application level by file I/O. Write a tray application that monitors that data.

JohnHyde

  • Member
  • ***
  • Posts: 4
Re: USB Audio Jack Information Reporting
« Reply #2 on: November 12, 2010, 11:07:34 am »
From your description, you have a USB device that has an audio jack.  If nothing is plugged into the audio jack then you don't want the audio function enabled, if something is plugged in then you want the audio function enabled, correct?

I am also assuming that this is a bus powered device so it needs to be plugged into USB to operate.

Build the device such that, on initial plug it, it enumerates as a generic HID.  You do this so that your device can get power and the on-board microcontroller can do some work.  It detects if there is something connected to your jack; if nothing is connected then it goes to sleep waiting for something to be plugged in; if something is connected then it drops the connection to the PC and reconnects as an audio device.

This way, Windows (or any other USB-aware OS) will only see your audio device if there is something plugged into your jack.

Regards,  John

fwdev7

  • Member
  • ***
  • Posts: 3
Re: USB Audio Jack Information Reporting
« Reply #3 on: November 15, 2010, 11:17:55 am »
Thank you for your suggestions.

Guido, while we do have a software component to our product, it is optional and not everyone will have our software installed so we would prefer for it to work without any special software.

John, our device is a self powered device so we don't have to worry about powering our micro. Our device is also a composite HID + Audio class device. The HID portion is a touch screen device that is always active, and our software (if installed) stores calibration and alignment data in the registry based on our Product ID. We have tried enumerating as a HID only device and then when something is plugged in to re-enumerate as a HID + Audio device but unfortunately Windows caches our device descriptors based on our VID & PID so then we get errors in the device manager when we change descriptors. It's like Windows is saying, "If you're the same device as before why do you have different descriptors?" So we figured out that on Win XP, they don't cache our audio format descriptor, and that's why changing the sampling frequency works. But it looks like on Win7 they started caching that descriptor too, so we can't change it if we have the same PID/VID. And as I stated earlier, we don't want different PIDs for our HID only, and HID + Audio, because it would complicate things for our software, although it's beginning to look like we will need a software solution to this issue.

Thanks for your input guys.

Guido Koerber

  • Frequent Contributor
  • ****
  • Posts: 72
Re: USB Audio Jack Information Reporting
« Reply #4 on: November 15, 2010, 06:32:23 pm »
If you want to do the reenumeration thing you have to use two different PIDs, no way around this. Have had the same issue with a device that enumerates for the highest available power. The Windows USB implementation is s***, storing dynamic data in a static structure is insane.

fwdev7

  • Member
  • ***
  • Posts: 3
Re: USB Audio Jack Information Reporting
« Reply #5 on: February 08, 2011, 12:43:14 pm »
Just in case anyone is wondering, we ended up disconnecting and reconnecting using a new PID as opposed to just sending a message to our software.