Bug 117598 - [snd_uaudio] [patch] Not possible to record with Plantronics DSP-400 USB headset
Summary: [snd_uaudio] [patch] Not possible to record with Plantronics DSP-400 USB headset
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 7.0-BETA1
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-usb mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-28 11:10 UTC by Henrik Gulbrandsen
Modified: 2018-01-03 05:16 UTC (History)
0 users

See Also:


Attachments
file.diff (2.66 KB, patch)
2007-10-28 11:10 UTC, Henrik Gulbrandsen
no flags Details | Diff
dsp-400.diff (2.66 KB, patch)
2007-10-28 15:45 UTC, Henrik Gulbrandsen
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Henrik Gulbrandsen 2007-10-28 11:10:01 UTC
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.
Comment 1 Hans Petter Selasky 2007-10-28 12:27:24 UTC
What you experience is very common and I think that a quirk would be useless. 
How about assuming ASYNC by default ?

--HPS
Comment 2 Henrik Gulbrandsen 2007-10-28 13:43:07 UTC
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
Comment 3 M. Warner Losh 2007-10-28 13:50:45 UTC
If the patch is reliable (eg, we get no false positives from the
printf), then we should eliminate the quirk.

Warner
Comment 4 Henrik Gulbrandsen 2007-10-28 15:45:46 UTC
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.
Comment 5 jakemsr 2009-10-23 20:38:44 UTC
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.




      
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:00:53 UTC
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