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@xxxxxxxxxxxxx/
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!
