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