[alsa-devel] S24_LE Mode for USB Driver
tiwai at suse.de
Wed Aug 13 14:55:16 CEST 2008
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) = 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
> ([actual_bits_per_sample] >
> bBitResolution) or interpret trailing zeros as significant bits
> ([actual_bits_per_sample] <
> 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.
More information about the Alsa-devel