S24_LE Mode for USB Driver

S24_LE Mode for USB Driver

[Charles Eidsness]

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

Re: S24_LE Mode for USB Driver

[Takashi Iwai]

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

Re: S24_LE Mode for USB Driver

[Clemens Ladisch]

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

Re: S24_LE Mode for USB Driver

[Takashi Iwai]

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

Re: 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

Re: 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

Re: S24_LE Mode for USB Driver

[Charles Eidsness]

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