S24LE and S32LE format equivalency

[Marios Sioutis]

Takashi,

Thanks for taking the time to answer.

On 12/12/21 20:51, Takashi Sakamoto wrote:
> Hi,
>
> On Sun, Dec 12, 2021 at 08:16:57PM +0900, Marios Sioutis wrote:
>> Hi all,
>>
>> Quick question, I was troubleshooting a 24bit USB device and got down the
>> rabbit hole of sample formats. The device advertises itself as S24LE (4byte
>> payload) but it appears as S32LE under alsa, something that bothered me a
>> lot initially. However, If the conversion between the two formats is to just
>> << 8 i.e. put a zero byte as LSB, then the two formats are essentially
>> equivalent.
>>
>> Is this actually the case? If yes, who performs the conversion? Is it on the
>> alsa side, or the device already adds a zero byte LSB?
>>
>> Thank you in advance,
>>
>> Marios
>   
> I think the format of sample is 'left-justified' or 'right-padding' 24
> bit in 32 bit frame. For the case, in ALSA PCM interface, [S|U]32 sample format is
> used with 'msbits' hardware parameter. The snd-ua101 USB driver might be
> an good example for the case.
>
>   * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/usb/misc/ua101.c#n615
>
> In detail, please refer to my previous patch:
>
>   * https://lore.kernel.org/alsa-devel/20210529033353.21641-1-o-takashi@sakamocchi.jp/

A left-justified format, with USB being a LSB first protocol would mean 
that an S24LE device would send a sample as:

(LSB) oooooooo oooooooo oooooooo xxxxxxxx(MSB)

x = zeroes, garbage, who knows! (trailing bits)

o = actual payload.

I was wondering how these trailing x bits are treated and I looked up 
the USB specification for the Audio Data Formats. Section 2.2.2. states:

"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)."

That is, in our case the trailing x bits should be discarded. I had a 
problem that could be explained if these trailing x bits *weren't* 
discarded, but I'm sure alsa is doing the correct thing here, or else 
pretty much every 24bit device in existence would be broken.

This is good enough for me. Unless there's a serious mistake in anything 
said above, consider my question answered.

Thank you for your time!