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.
In detail, please refer to my previous patch:
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