The Plantronics DSP-400 USB headset works fine for playback, but recording fails. A look at /dev/sndstat indicated that there were no recording channels available, and the relevant lines from /var/log/messages are as follows: Oct 25 17:37:43 root: Unknown USB device: vendor 0x047f product 0x0ca1 bus uhub2 Oct 25 17:37:43 kernel: uaudio0: <Plantronics Plantronics Headset, class 0/0, rev 1.10/0.04, addr 2> on uhub2 Oct 25 17:37:43 kernel: uaudio0: ignored input endpoint of type adaptive Oct 25 17:37:43 last message repeated 2 times Oct 25 17:37:43 kernel: uaudio0: audio rev 1.00 Oct 25 17:37:43 kernel: pcm0: <USB Audio> on uaudio0 Apparently, the headset reports using an adaptive audio source endpoint for data from the microphone. According to the USB specs, such endpoints need an explicit synch pipe to specify the wanted sample rate [See USB Spec rev 2.0, sec. 5.12.4.2 "Feedback" and the USB Device Class Definition for Audio Devices, sec. 3.7.2.2 "Isochronous Synch Endpoint"]. Unfortunately, FreeBSD currently doesn't support these synch endpoints. Fortunately, neither does the DSP-400 :-) The rest of the story follows in the fix description... Fix: Recompiling sys/dev/sound/usb/uaudio.c with defined UAUDIO_MULTIPLE_ENDPOINTS revealed that that the required synch endpoint didn't exist. There is already a USB quirk flag UQ_AU_INP_ASYNC, which specifies that a claimed adaptive input is in fact not adaptive at all, but better handled as asynchronous. After setting the flag for the DSP-400 headset, recording seems to work without obvious flaws. I'm attaching a patch that adds this to the set of known quirks. Since this has happened at least twice, I'm also adding some optional code that assumes that all cases with a mysteriously missing sync endpoint should be handled similarly. This may help to save some debugging time for other problem devices out there... Patch attached with submission follows: How-To-Repeat: Plug in your Plantronics DSP-400 headset and make sure that the snd_uaudio kernel module is loaded. Verify that playback works and recording fails.
What you experience is very common and I think that a quirk would be useless. How about assuming ASYNC by default ? --HPS
On Sun, 2007-10-28 at 14:27 +0200, Hans Petter Selasky wrote: > What you experience is very common and I think that a quirk would be useless. > How about assuming ASYNC by default ? Well, I couldn't think of a good reason not to, so that's why you'll find a "#define UAUDIO_ASSUME_ASYNC" at the beginning of the patch. I just wanted to make it easy to turn it off, just in case someone else could think of a good reason why that would be better - and the quirk fix is there to ensure that my own headset keeps working in that case. I wouldn't have added the quirk flag if it wasn't for the fact that it was already there. In a case like this, I'd prefer to work around the problem once and for all. See the usb/78984 patch for example. That was never applied, by the way. I probably missed some administrative detail. /Henrik
If the patch is reliable (eg, we get no false positives from the printf), then we should eliminate the quirk. Warner
On Sun, 2007-10-28 at 07:50 -0600, M. Warner Losh wrote: > If the patch is reliable (eg, we get no false positives from the > printf), then we should eliminate the quirk. True, but this would require at least a small leap of faith, since I haven't analyzed the consequences in detail. All I know is that we are currently handling this as an error situation and return USBD_INVAL. Assuming an asynchronous endpoint and continuing will work around the problem if this is indeed what the device expects, but it may lead to other bugs if the core problem is something else. My qualified guess is that this will probably help more often than it hurts, so I enabled UAUDIO_ASSUME_ASYNC by default. If we check this in and nobody complains in the near future, then it's probably safe to do as you say and eliminate the quirk (and the printf) in a later version. /Henrik P.S. The patch is virtually unreadable in the web version, so I'm attaching it again, hoping to get better formatting this time.
you may be interested in recent changes to OpenBSD's uaudio(4). http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/uaudio.c?only_with_tag=MAIN and also http://marc.info/?l=openbsd-tech&m=125518948020717&w=2 and http://marc.info/?l=openbsd-tech&m=125560448608713&w=2 for more background on the change.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped