[alsa-devel] S24_LE Mode for USB Driver

[Takashi Iwai]

At Wed, 13 Aug 2008 08:39:29 -0400,
Charles Eidsness wrote:
> 
> 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.

We can put msbits hwparams to indicate that only 24bits are used.
But most apps simply ignore this and checks only the format.  So, I
don't think this would help in practice.


Takashi