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
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user
