[alsa-devel] S24_LE Mode for USB Driver
Hi All,
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.
Thanks! Charles
At Thu, 07 Aug 2008 16:25:50 -0400, Charles Eidsness wrote:
Hi All,
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...
thanks,
Takashi
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.)
Regards, Clemens
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.
Takashi
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
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
Takashi Iwai wrote:
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 practise.
Thanks Takashi but it's probably not worth it.
Cheers, Charles
participants (3)
-
Charles Eidsness -
Clemens Ladisch -
Takashi Iwai