[alsa-devel] S24_LE Mode for USB Driver
charles.eidsness at ieee.org
Wed Aug 13 14:39:29 CEST 2008
Takashi Iwai wrote:
> At Wed, 13 Aug 2008 13:17:44 +0200,
> Clemens Ladisch wrote:
>> Takashi Iwai wrote:
>>> Charles Eidsness wrote:
>>>> It looks like the parse_audio_format_i_type function at line 2369 of usbaudio.c
>>>> (linux v2.6.23) doesn't support the case where bSubframeSize (fmt) = 4 bytes
>>>> and bBitResolution (fmt) = 24 bits, which should correspond to a S24_LE (or
>>>> BE) type. I'm developing a new USD DAC which supports this mode (24-bit sample
>>>> in a 4 byte package). Right now Linux sends me S32_LE formated data, which is
>>>> wrong. Would it be possible to expand this function to support S24_LE/BE? It
>>>> would only require adding a few lines of code.
>>> Yes, it's possible, of course.
>>> BTW, is this behavior strictly defined? I fail to find in the
>>> usb-audio spec that bBitResolution specifies the lower bits, not the
>>> higher bits...
>> The spec assumes that 24-bit samples use S24_3LE. 24-bit samples in
>> 32-bit words are an extension that must be handled with some device-
>> specific code (like with the UA-1000).
>> (The audio 2.0 spec allows 32-bit words, and the wording seems to imply
>> that samples are aligned to the most significant bit, i.e., that S32_LE
>> would be used in this case.)
> OK, thanks for clarification.
Right, I guess I should have read the spec a little closer (for anyone following
along without the Spec handy), from section 2.2.2 of the USB Audio Data Formats
Spec (page 9 of http://www.usb.org/developers/devclass_docs/frmts10.pdf):
"AudioStreaming endpoints must be constructed in such a way that a valid
transfer can take place as long
as the reported audio subframe size (bSubframeSize) is respected during
transmission. If the reported bits
per sample (bBitResolution) do not correspond with the number of significant
bits actually used during
transfer, the device will either discard trailing significant bits
bBitResolution) or interpret trailing zeros as significant bits
Unfortunately for me this means that if I want to avoid the extra discretization
distortion that comes with truncating those bottom 8-bits I'll have to add a
dither function to my DAC.
More information about the Alsa-devel