Thread: [Alsa-user] snd-usb-audio : issue sending "set sample freq"
Brought to you by:
perex
From: Yves G <als...@vi...> - 2013-04-22 16:39:10
|
Hello - I work with a partner who is a USB headset manufacturer. Recently, they made a change to the firmware of one of their USB headsets and now the default playing sampling rate is 16kHz instead of 48kHz. This device supports only 16kHz and 48kHz for output sample rates. Now, when using alsa, we can't play anything on this device but 16kHz samples. Previously, when the device's default output sample frequency was 48kHz, everything seemed OK (though I must admit that I did not try to play 16kHz samples then. And I can't downgrade the firmware so I can't do the test) We recorded USB packets and we compared Linux and Windows traces. When under Windows, we can see that a USB packet to set the device sampling rate is sent (even if the default sampling rate freq is already 48kHz. The USB packet is "Set Cur", "Endpoint=3-OUT CS=SAMPLING_FREQ_CONTROL"). When under Linux using Alsa, the message is never sent. I nailed the problem down to alsa driver since it can be reproduced by using aplay and specifying directly the hardware device (-D hw:2,0 for instance) bypassing all the other components. I tested with Ubuntu 10.04 LTS and 12.04 with the same results. I found a workaround which is to set the software mixer (PulseAudio in our cases) to use 16kHz as its default sample rate, but this is not acceptable since everything would then be down-sampled to 16kHz. Is there something we can do? Maybe some parameter configuration or rule that would force the system to send the USB message to set the device output sample rate freq? I tried to take a look at the usb-audio driver sources but I lack expertise in that domain. I wanted, in particular, to check under what conditions the message to set the device output sample rate frequency is sent. I have access to the firmware engineer at the partner's, so if there is something to correct or implement in the firmware, this may be doable. Thanks in advance.. (if this message would have been better posted in asla-devel, please let me know) Thanks in advance - Yves |
From: Daniel M. <zo...@gm...> - 2013-04-22 16:57:25
|
Hi Yves, On 22.04.2013 18:20, Yves G wrote: > I work with a partner who is a USB headset manufacturer. > Recently, they made a change to the firmware of one of their USB > headsets and now the default playing sampling rate is 16kHz instead of > 48kHz. This device supports only 16kHz and 48kHz for output sample rates. > Now, when using alsa, we can't play anything on this device but 16kHz > samples. > Previously, when the device's default output sample frequency was 48kHz, > everything seemed OK (though I must admit that I did not try to play > 16kHz samples then. And I can't downgrade the firmware so I can't do the > test) I suspect there was always something wrong on the firmware side, and the changed default just brought it to the surface. > We recorded USB packets and we compared Linux and Windows traces. > When under Windows, we can see that a USB packet to set the device > sampling rate is sent (even if the default sampling rate freq is already > 48kHz. The USB packet is "Set Cur", "Endpoint=3-OUT > CS=SAMPLING_FREQ_CONTROL"). Please show the contents of /proc/asound/cardX/stream0. > When under Linux using Alsa, the message is never sent. Maybe because the descriptors don't allow that. Please post the output of 'lsusb -v'. > I have access to the firmware engineer at the partner's, so if there is > something to correct or implement in the firmware, this may be doable. That's good. Is this device already shipping or can we expect the firmware to get fixed before that happens? Thanks, Daniel |
From: Yves G <als...@vi...> - 2013-04-22 18:13:34
|
Thanks for the quick answer. Here are the requested details: ============================ stream0: Plantronics Plantronics C720 at usb-0000:00:12.0-1, full speed : USB Audio Playback: Status: Stop Interface 1 Altset 1 Format: S16_LE Channels: 2 Endpoint: 3 OUT (NONE) Rates: 16000, 48000 Capture: Status: Stop Interface 2 Altset 1 Format: S16_LE Channels: 1 Endpoint: 3 IN (NONE) Rates: 16000 ============================ lsusb -v: Bus 002 Device 002: ID 047f:010a Plantronics, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x047f Plantronics, Inc. idProduct 0x010a bcdDevice 0.41 iManufacturer 1 Plantronics iProduct 2 Plantronics C720 iSerial 3 90cee226da877041a974763f72f2a0bb bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 269 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 119 bInCollection 2 baInterfaceNr( 0) 1 baInterfaceNr( 1) 2 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Microphone bAssocTerminal 7 bNrChannels 1 wChannelConfig 0x0004 Center Front (C) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 2 bSourceID 1 bControlSize 2 bmaControls( 0) 0x01 bmaControls( 0) 0x00 Mute bmaControls( 1) 0x02 bmaControls( 1) 0x00 Volume iFeature 0 AudioControl Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 5 (SELECTOR_UNIT) bUnitID 3 bNrInPins 1 baSource( 0) 2 iSelector 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 4 wTerminalType 0x0101 USB Streaming bAssocTerminal 5 bSourceID 3 iTerminal 0 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 5 wTerminalType 0x0101 USB Streaming bAssocTerminal 4 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 13 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 6 bSourceID 9 bControlSize 2 bmaControls( 0) 0x01 bmaControls( 0) 0x00 Mute bmaControls( 1) 0x02 bmaControls( 1) 0x00 Volume bmaControls( 2) 0x02 bmaControls( 2) 0x00 Volume iFeature 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 7 wTerminalType 0x0301 Speaker bAssocTerminal 1 bSourceID 6 iTerminal 0 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 10 wTerminalType 0x0201 Microphone bAssocTerminal 0 bNrChannels 1 wChannelConfig 0x0004 Center Front (C) iChannelNames 0 iTerminal 6 Sidetone AudioControl Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 8 bSourceID 10 bControlSize 2 bmaControls( 0) 0x01 bmaControls( 0) 0x00 Mute bmaControls( 1) 0x02 bmaControls( 1) 0x00 Volume iFeature 0 AudioControl Interface Descriptor: bLength 13 bDescriptorType 36 bDescriptorSubtype 4 (MIXER_UNIT) bUnitID 9 bNrInPins 2 baSourceID( 0) 5 baSourceID( 1) 8 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 bmControls 0x00 iMixer 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 5 bDelay 0 frames wFormatTag 1 PCM AudioStreaming Interface Descriptor: bLength 14 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 2 Discrete tSamFreq[ 0] 16000 tSamFreq[ 1] 48000 ** UNRECOGNIZED: 07 25 01 81 02 00 00 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x00c0 1x 192 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 4 bDelay 0 frames wFormatTag 1 PCM AudioStreaming Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 1 bSubframeSize 2 bBitResolution 16 bSamFreqType 1 Discrete tSamFreq[ 0] 16000 ** UNRECOGNIZED: 07 25 01 00 02 00 00 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.11 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 788 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Device Status: 0x0001 Self Powered ============================ The device is shipping, but usually with the default firmware, it works OK. There is a utility to update the firmware, and only the "latest and greatest" is available then. So if we get a correction, it could make its way to the end-user. I'll ask if I can get some more support from Plantronics Thanks in advance - Yves On 22/04/2013 18:57, Daniel Mack wrote: > Hi Yves, > > On 22.04.2013 18:20, Yves G wrote: >> I work with a partner who is a USB headset manufacturer. >> Recently, they made a change to the firmware of one of their USB >> headsets and now the default playing sampling rate is 16kHz instead of >> 48kHz. This device supports only 16kHz and 48kHz for output sample rates. >> Now, when using alsa, we can't play anything on this device but 16kHz >> samples. >> Previously, when the device's default output sample frequency was 48kHz, >> everything seemed OK (though I must admit that I did not try to play >> 16kHz samples then. And I can't downgrade the firmware so I can't do the >> test) > I suspect there was always something wrong on the firmware side, and the > changed default just brought it to the surface. > >> We recorded USB packets and we compared Linux and Windows traces. >> When under Windows, we can see that a USB packet to set the device >> sampling rate is sent (even if the default sampling rate freq is already >> 48kHz. The USB packet is "Set Cur", "Endpoint=3-OUT >> CS=SAMPLING_FREQ_CONTROL"). > Please show the contents of /proc/asound/cardX/stream0. > >> When under Linux using Alsa, the message is never sent. > Maybe because the descriptors don't allow that. Please post the output > of 'lsusb -v'. > >> I have access to the firmware engineer at the partner's, so if there is >> something to correct or implement in the firmware, this may be doable. > That's good. Is this device already shipping or can we expect the > firmware to get fixed before that happens? > > > Thanks, > Daniel > |
From: Daniel M. <zo...@gm...> - 2013-04-22 18:44:35
|
On 22.04.2013 20:13, Yves G wrote: > Thanks for the quick answer. > > Here are the requested details: > > ============================ > > stream0: > > Plantronics Plantronics C720 at usb-0000:00:12.0-1, full speed : USB Audio > > Playback: > Status: Stop > Interface 1 > Altset 1 > Format: S16_LE > Channels: 2 > Endpoint: 3 OUT (NONE) > Rates: 16000, 48000 > > Capture: > Status: Stop > Interface 2 > Altset 1 > Format: S16_LE > Channels: 1 > Endpoint: 3 IN (NONE) > Rates: 16000 So the capture device only supports 16000Hz, because the capture endpoint only carries one discrete sample format (as seen in the lsusb dumps). Is that on purpose? Also, the lsusb dumps don't contain a audio specific header descriptor, which normally looks like this: AudioControl Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0 Undefined And without the "Sampling Frequency" bit in bmAttributes, the driver will bail out early (clock.c): /* if endpoint doesn't have sampling rate control, bail out */ if (!(fmt->attributes & UAC_EP_CS_ATTR_SAMPLE_RATE)) return 0; That explains why the driver won't switch sample rates for the playback endpoint. And your Windows driver just doesn't look at that bit, which is what device-specific Windows tend to do. Please make the firmware developers fix at least the latter point, which is clearly bug. Best regards, Daniel |
From: Torstein H. <he...@re...> - 2013-04-22 19:23:46
|
On Mon, Apr 22, 2013 at 20:44:40 +0200, Daniel Mack wrote: > Also, the lsusb dumps don't contain a audio specific header descriptor, > which normally looks like this: > > AudioControl Endpoint Descriptor: > bLength 7 > bDescriptorType 37 > bDescriptorSubtype 1 (EP_GENERAL) > bmAttributes 0x01 > Sampling Frequency > bLockDelayUnits 0 Undefined > wLockDelay 0 Undefined > > And without the "Sampling Frequency" bit in bmAttributes, the driver > will bail out early (clock.c): I think it has the class specific endpoint descriptor, but it is in front of the standard endpoint descriptor. From the 'lsusb -v': AudioStreaming Interface Descriptor: bLength 14 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 2 Discrete tSamFreq[ 0] 16000 tSamFreq[ 1] 48000 ** UNRECOGNIZED: 07 25 01 81 02 00 00 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x00c0 1x 192 bytes bInterval 1 bRefresh 0 bSynchAddress 0 The UNRECOGNIZED bit matches the missing AudioControl endpoint descriptor. Even if this is against the specification, devices that does this is out there. I have seen the same thing on a Sennheiser BTD-500, but that only supports one frequency, so I didn't hit this problem. Torstein |
From: Daniel M. <zo...@gm...> - 2013-04-22 21:45:45
|
On 22.04.2013 21:23, Torstein Hegge wrote: > On Mon, Apr 22, 2013 at 20:44:40 +0200, Daniel Mack wrote: >> Also, the lsusb dumps don't contain a audio specific header descriptor, >> which normally looks like this: >> >> AudioControl Endpoint Descriptor: >> bLength 7 >> bDescriptorType 37 >> bDescriptorSubtype 1 (EP_GENERAL) >> bmAttributes 0x01 >> Sampling Frequency >> bLockDelayUnits 0 Undefined >> wLockDelay 0 Undefined >> >> And without the "Sampling Frequency" bit in bmAttributes, the driver >> will bail out early (clock.c): > > I think it has the class specific endpoint descriptor, but it is in > front of the standard endpoint descriptor. From the 'lsusb -v': > > AudioStreaming Interface Descriptor: > bLength 14 > bDescriptorType 36 > bDescriptorSubtype 2 (FORMAT_TYPE) > bFormatType 1 (FORMAT_TYPE_I) > bNrChannels 2 > bSubframeSize 2 > bBitResolution 16 > bSamFreqType 2 Discrete > tSamFreq[ 0] 16000 > tSamFreq[ 1] 48000 > ** UNRECOGNIZED: 07 25 01 81 02 00 00 > Endpoint Descriptor: > bLength 9 > bDescriptorType 5 > bEndpointAddress 0x03 EP 3 OUT > bmAttributes 1 > Transfer Type Isochronous > Synch Type None > Usage Type Data > wMaxPacketSize 0x00c0 1x 192 bytes > bInterval 1 > bRefresh 0 > bSynchAddress 0 > > The UNRECOGNIZED bit matches the missing AudioControl endpoint > descriptor. Ah, yes, good catch. > Even if this is against the specification, devices that does this is out > there. I have seen the same thing on a Sennheiser BTD-500, but that only > supports one frequency, so I didn't hit this problem. Yes, if that's the case, we should patch both lsusb and the snd-usb driver. Let's see who provides a patch first :) Daniel |
From: Daniel M. <zo...@gm...> - 2013-04-22 21:48:39
|
On 22.04.2013 22:07, Yves G wrote: > Thanks. > Do you mean that if "07 25 01 81 02 00 00" (Unrecognized) was moved > after the "Endpoint Descriptor", then the driver should recognize it as > some AudioControl Endpoint Descriptor (as described in Table 4-21: > Class-Specific AS Isochronous Audio Data Endpoint Descripton in > http://www.usb.org/developers/devclass_docs/audio10.pdf)? > I have no idea if this is an easy modification (it does not sound > complex to me, but I never wrote firmware for USB audio devices!) It's really just about moving a block of data around. But Torstein is right, we should rather fix the driver here. Daniel |
From: Daniel M. <zo...@gm...> - 2013-04-22 22:19:53
Attachments:
snd-usb-try-to-find-csep-harder.diff
|
On 22.04.2013 21:23, Torstein Hegge wrote: > On Mon, Apr 22, 2013 at 20:44:40 +0200, Daniel Mack wrote: >> Also, the lsusb dumps don't contain a audio specific header descriptor, >> which normally looks like this: >> >> AudioControl Endpoint Descriptor: >> bLength 7 >> bDescriptorType 37 >> bDescriptorSubtype 1 (EP_GENERAL) >> bmAttributes 0x01 >> Sampling Frequency >> bLockDelayUnits 0 Undefined >> wLockDelay 0 Undefined >> >> And without the "Sampling Frequency" bit in bmAttributes, the driver >> will bail out early (clock.c): > > I think it has the class specific endpoint descriptor, but it is in > front of the standard endpoint descriptor. From the 'lsusb -v': > > AudioStreaming Interface Descriptor: > bLength 14 > bDescriptorType 36 > bDescriptorSubtype 2 (FORMAT_TYPE) > bFormatType 1 (FORMAT_TYPE_I) > bNrChannels 2 > bSubframeSize 2 > bBitResolution 16 > bSamFreqType 2 Discrete > tSamFreq[ 0] 16000 > tSamFreq[ 1] 48000 > ** UNRECOGNIZED: 07 25 01 81 02 00 00 > Endpoint Descriptor: > bLength 9 > bDescriptorType 5 > bEndpointAddress 0x03 EP 3 OUT > bmAttributes 1 > Transfer Type Isochronous > Synch Type None > Usage Type Data > wMaxPacketSize 0x00c0 1x 192 bytes > bInterval 1 > bRefresh 0 > bSynchAddress 0 > > The UNRECOGNIZED bit matches the missing AudioControl endpoint > descriptor. > > Even if this is against the specification, devices that does this is out > there. I have seen the same thing on a Sennheiser BTD-500, but that only > supports one frequency, so I didn't hit this problem. But it should still complain about "no or invalid class specific endpoint descriptor", right? If you have time, please check the attached (totally untested) patch. Let's see. Yves - did you ever compile and run your own kernel? Then please also try this patch. Thanks, Daniel |
From: Torstein H. <he...@re...> - 2013-04-22 22:34:40
|
On Tue, Apr 23, 2013 at 00:19:57 +0200, Daniel Mack wrote: > On 22.04.2013 21:23, Torstein Hegge wrote: > > Even if this is against the specification, devices that does this is out > > there. I have seen the same thing on a Sennheiser BTD-500, but that only > > supports one frequency, so I didn't hit this problem. > > But it should still complain about "no or invalid class specific > endpoint descriptor", right? Yes, it does. I must have missed that before. > If you have time, please check the attached (totally untested) patch. > Let's see. With the patch applied the warning is silenced. The patch doesn't affect anything else, the BTD-500 plays at the first and only sample rate it knows, as expected. |
From: Clemens L. <cla...@go...> - 2013-04-23 07:19:54
|
Yves G wrote: > Can someone point me to the spec where it is said that the > AudioControl Endpoint Descriptor should be located after the Endpoint > Descriptor? USB Specification 2.0 section 9.5 no. 1: | If the class or vendor specific descriptors use the same format as | standard descriptors (e.g., start with a length byte and followed by | a type byte), they must be returned interleaved with standard | descriptors in the configuration information returned by | a GetDescriptor(Configuration) request. In this case, the class or | vendor-specific descriptors must follow a related standard descriptor | they modify or extend. Regards, Clemens |
From: Yves G <als...@vi...> - 2013-04-23 11:08:06
|
Thanks! I'll forward that to my contacts at Plantronics Regards - Yves On 23/04/2013 09:19, Clemens Ladisch wrote: > Yves G wrote: >> Can someone point me to the spec where it is said that the >> AudioControl Endpoint Descriptor should be located after the Endpoint >> Descriptor? > USB Specification 2.0 section 9.5 no. 1: > | If the class or vendor specific descriptors use the same format as > | standard descriptors (e.g., start with a length byte and followed by > | a type byte), they must be returned interleaved with standard > | descriptors in the configuration information returned by > | a GetDescriptor(Configuration) request. In this case, the class or > | vendor-specific descriptors must follow a related standard descriptor > | they modify or extend. > > > Regards, > Clemens |
From: Daniel M. <zo...@gm...> - 2013-04-23 11:14:50
|
On 23.04.2013 13:07, Yves G wrote: > Thanks! > > I'll forward that to my contacts at Plantronics Fixing the firmware is certainly the right thing to do, but I'd appreciate if you could still test my patch, so we can take it to the mainline kernel. As Torstein said - there are more devices out there which get this wrong, and I'd like to fix all of them at once. Thanks, Daniel |
From: Yves G <als...@vi...> - 2013-04-23 11:19:50
|
On 23/04/2013 13:14, Daniel Mack wrote: > On 23.04.2013 13:07, Yves G wrote: >> Thanks! >> >> I'll forward that to my contacts at Plantronics > Fixing the firmware is certainly the right thing to do, but I'd > appreciate if you could still test my patch, so we can take it to the > mainline kernel. As Torstein said - there are more devices out there > which get this wrong, and I'd like to fix all of them at once. > It is my plan to do it today or tomorrow. I'll tell you the results. BTW: The patch does not work with the version of Alsa shipped with Ubuntu 10.04. In that version, this is usbaudio.c that must be patched, not stream.c. But I guess that it can be made available only with the latest version of Alsa (which then may not work with older systems...) Regards - Yves > Thanks, > Daniel > |
From: Daniel M. <zo...@gm...> - 2013-04-23 11:24:51
|
On 23.04.2013 13:19, Yves G wrote: > On 23/04/2013 13:14, Daniel Mack wrote: >> On 23.04.2013 13:07, Yves G wrote: >>> Thanks! >>> >>> I'll forward that to my contacts at Plantronics >> Fixing the firmware is certainly the right thing to do, but I'd >> appreciate if you could still test my patch, so we can take it to the >> mainline kernel. As Torstein said - there are more devices out there >> which get this wrong, and I'd like to fix all of them at once. >> > It is my plan to do it today or tomorrow. > I'll tell you the results. Thanks. > BTW: The patch does not work with the version of Alsa shipped with > Ubuntu 10.04. In that version, this is usbaudio.c that must be patched, > not stream.c. Then the kernel they ship is ancient. > But I guess that it can be made available only with the latest version > of Alsa (which then may not work with older systems...) Don't bother with separate version of the kernel and ALSA. Just follow the instructions on this page and build a completely new kernel: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild You should apply my patch after you completed step 7, with "git apply <filename>". Best regards, Daniel |
From: Yves G <als...@vi...> - 2013-04-23 11:29:45
|
On 23/04/2013 13:24, Daniel Mack wrote: > On 23.04.2013 13:19, Yves G wrote: >> On 23/04/2013 13:14, Daniel Mack wrote: >>> On 23.04.2013 13:07, Yves G wrote: >>>> Thanks! >>>> >>>> I'll forward that to my contacts at Plantronics >>> Fixing the firmware is certainly the right thing to do, but I'd >>> appreciate if you could still test my patch, so we can take it to the >>> mainline kernel. As Torstein said - there are more devices out there >>> which get this wrong, and I'd like to fix all of them at once. >>> >> It is my plan to do it today or tomorrow. >> I'll tell you the results. > Thanks. > >> BTW: The patch does not work with the version of Alsa shipped with >> Ubuntu 10.04. In that version, this is usbaudio.c that must be patched, >> not stream.c. > Then the kernel they ship is ancient. Yes. 2.6.32-46-108. This is an old version of Ubuntu, but this is what is used as the OS of the devices I must support. >> But I guess that it can be made available only with the latest version >> of Alsa (which then may not work with older systems...) > Don't bother with separate version of the kernel and ALSA. Just follow > the instructions on this page and build a completely new kernel: > > https://wiki.ubuntu.com/KernelTeam/GitKernelBuild > > You should apply my patch after you completed step 7, with "git apply > <filename>". I'll try that too. For my current issue, however, I should be able to provide a fix that does not need a new/rebuilt kernel. So I'll also test a patched snd-usb-audio module. Regards - Yves > Best regards, > Daniel > |
From: Torstein H. <he...@re...> - 2013-04-23 12:40:34
|
On Mon, Apr 22, 2013 at 23:45:49 +0200, Daniel Mack wrote: > On 22.04.2013 21:23, Torstein Hegge wrote: > > Even if this is against the specification, devices that does this is out > > there. I have seen the same thing on a Sennheiser BTD-500, but that only > > supports one frequency, so I didn't hit this problem. > > Yes, if that's the case, we should patch both lsusb and the snd-usb > driver. Let's see who provides a patch first :) I think the lsusb patch should look something like this. Unless you have objections, I'll try to poke Greg KH via the linux-usb mailing list. -- >8 -- Subject: [PATCH] lsusb: Parse misplaced UAC1 AudioControl Endpoint Descriptor Some UAC devices (Sennheiser BTD-500 and some firmware revisions of Plantronics USB headsets) has the class specific endpoint descriptor in front of the standard endpoint descriptor. Print the "AudioControl Endpoint Descriptor" where it appears, instead of showing "UNRECOGNIZED". --- lsusb.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/lsusb.c b/lsusb.c index 5118114..470146c 100644 --- a/lsusb.c +++ b/lsusb.c @@ -586,6 +586,22 @@ static void dump_altsetting(libusb_device_handle *dev, const struct libusb_inter goto dump; } break; + case LIBUSB_CLASS_AUDIO: + switch (buf[1]) { + /* MISPLACED DESCRIPTOR */ + case USB_DT_CS_ENDPOINT: + switch (interface->bInterfaceSubClass) { + case 2: + dump_audiostreaming_endpoint(buf, interface->bInterfaceProtocol); + break; + default: + goto dump; + } + break; + default: + goto dump; + } + break; default: /* ... not everything is class-specific */ switch (buf[1]) { -- 1.7.10.4 |
From: Daniel M. <zo...@gm...> - 2013-04-23 12:44:56
|
On 23.04.2013 14:40, Torstein Hegge wrote: > On Mon, Apr 22, 2013 at 23:45:49 +0200, Daniel Mack wrote: >> On 22.04.2013 21:23, Torstein Hegge wrote: >>> Even if this is against the specification, devices that does this is out >>> there. I have seen the same thing on a Sennheiser BTD-500, but that only >>> supports one frequency, so I didn't hit this problem. >> >> Yes, if that's the case, we should patch both lsusb and the snd-usb >> driver. Let's see who provides a patch first :) > > I think the lsusb patch should look something like this. Unless you have > objections, I'll try to poke Greg KH via the linux-usb mailing list. Looks good to me, but I can't test it. You can also send Greg pull requests on GitHub, he'll pick them from there. https://github.com/gregkh/usbutils Best, Daniel > > -- >8 -- > Subject: [PATCH] lsusb: Parse misplaced UAC1 AudioControl Endpoint Descriptor > > Some UAC devices (Sennheiser BTD-500 and some firmware revisions of > Plantronics USB headsets) has the class specific endpoint descriptor in > front of the standard endpoint descriptor. Print the "AudioControl > Endpoint Descriptor" where it appears, instead of showing > "UNRECOGNIZED". > --- > lsusb.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/lsusb.c b/lsusb.c > index 5118114..470146c 100644 > --- a/lsusb.c > +++ b/lsusb.c > @@ -586,6 +586,22 @@ static void dump_altsetting(libusb_device_handle *dev, const struct libusb_inter > goto dump; > } > break; > + case LIBUSB_CLASS_AUDIO: > + switch (buf[1]) { > + /* MISPLACED DESCRIPTOR */ > + case USB_DT_CS_ENDPOINT: > + switch (interface->bInterfaceSubClass) { > + case 2: > + dump_audiostreaming_endpoint(buf, interface->bInterfaceProtocol); > + break; > + default: > + goto dump; > + } > + break; > + default: > + goto dump; > + } > + break; > default: > /* ... not everything is class-specific */ > switch (buf[1]) { > |
From: Yves G <als...@vi...> - 2013-04-23 16:29:51
|
First test I could make, patching the usbaudio.c source from ubuntu 10.04 with your patch. Now the device can play sounds at 48kHz on the Plantronics C720. However, I can't play sounds at 16kHz anymore, I get clicks instead (exactly like it was previously when trying to play 48kHz sounds with the device set to 16kHz). I use aplay -D hw:1,0 to run the tests (bypassing pulse etc) I'll make further tests when I can and keep you posted. Thanks - Yves On 23/04/2013 13:29, Yves G wrote: > On 23/04/2013 13:24, Daniel Mack wrote: >> On 23.04.2013 13:19, Yves G wrote: >>> On 23/04/2013 13:14, Daniel Mack wrote: >>>> On 23.04.2013 13:07, Yves G wrote: >>>>> Thanks! >>>>> >>>>> I'll forward that to my contacts at Plantronics >>>> Fixing the firmware is certainly the right thing to do, but I'd >>>> appreciate if you could still test my patch, so we can take it to the >>>> mainline kernel. As Torstein said - there are more devices out there >>>> which get this wrong, and I'd like to fix all of them at once. >>>> >>> It is my plan to do it today or tomorrow. >>> I'll tell you the results. >> Thanks. >> >>> BTW: The patch does not work with the version of Alsa shipped with >>> Ubuntu 10.04. In that version, this is usbaudio.c that must be patched, >>> not stream.c. >> Then the kernel they ship is ancient. > Yes. 2.6.32-46-108. > This is an old version of Ubuntu, but this is what is used as the OS > of the devices I must support. >>> But I guess that it can be made available only with the latest version >>> of Alsa (which then may not work with older systems...) >> Don't bother with separate version of the kernel and ALSA. Just follow >> the instructions on this page and build a completely new kernel: >> >> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild >> >> You should apply my patch after you completed step 7, with "git apply >> <filename>". > I'll try that too. > For my current issue, however, I should be able to provide a fix that > does not need a new/rebuilt kernel. So I'll also test a patched > snd-usb-audio module. > > Regards > > - Yves >> Best regards, >> Daniel >> > |
From: Daniel M. <zo...@gm...> - 2013-04-23 22:04:25
|
On 23.04.2013 18:29, Yves G wrote: > First test I could make, patching the usbaudio.c source from ubuntu > 10.04 with your patch. > Now the device can play sounds at 48kHz on the Plantronics C720. > However, I can't play sounds at 16kHz anymore, I get clicks instead > (exactly like it was previously when trying to play 48kHz sounds with > the device set to 16kHz). With the patch applied, could you please plug out the device, do a "sudo dmesg -c", then plug it back in and run "sudo dmesg -c" again, and send us the output. Also, I'd need to see the contents of /proc/asound/card1/stream0 again, to prove that the patch does the right thing. > I use aplay -D hw:1,0 to run the tests (bypassing pulse etc) Given that you seem to have access to an USB analyzer, can you look at the packets and see if there's anything wrong with them? And please also compare the setup sequence again, in comparison to what the Windows driver does. Thanks, Daniel |