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. 220.127.116.11 "Feedback" and the USB Device Class Definition for Audio Devices,
sec. 18.104.22.168 "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 ?
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.
If the patch is reliable (eg, we get no false positives from the
printf), then we should eliminate the quirk.
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.
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).
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