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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
