S24LE and S32LE format equivalency

[Takashi Sakamoto]

On Sun, Dec 12, 2021 at 10:03:32PM +0900, Marios Sioutis wrote:
> 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!

In your case, the format of sample is correctly [S|U]24 since it's LSB
first protocol. (The explanation in my previous message is aligned to host
endian.)

In regard of 'snd-usb-audio' implementation, the audio data frame
from/to URB for device is just copied to/from memory area shared with
userspace application. (see retire_capture_urb() and prepare_playback_urb()
in sound/usb/pcm.c.) So userspace application is responsible for the
invalidation of bits in MSB of audio sample.

But in ALSA usb audio stack, there are some drivers. So you may find a
driver to invalidate the bits voluntarily, perhaps.


Regards

Takashi Sakamoto