[alsa-devel] S24_LE Mode for USB Driver

[Charles Eidsness]

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[5]) = 4 bytes
>>>> and  bBitResolution (fmt[6]) = 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 
([actual_bits_per_sample] >
bBitResolution) or interpret trailing zeros as significant bits 
([actual_bits_per_sample] <
bBitResolution)."

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.

Thanks!
Charles