alsa subformat

[audiofool]

Should there be a setting for subformat?

Using aplay with --subformat=MSBITS_MAX vs --subformat=STD sounds different.

I am wondering if subformat=STD is truncating?

Found this info, though not sure if it is correct:
S16_LE + STD (maximum bits handled by driver - 16 in this case)
S16_LE + MSBITS_MAX (maximum physical bits for the format - 16)
S32_LE + STD (maximum bits handled by driver - 24 in this case)
S32_LE + MSBITS_MAX (maximum physical bits for the format - 32)
S32_LE + MSBITS_24
S32_LE + MSBITS_20

aplay --dump-hw-params -D hw:CARD=DX1,DEV=0 -f cd /dev/zero

ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S32_LE SPECIAL DSD_U32_BE
SUBFORMAT: STD MSBITS_MAX
SAMPLE_BITS: 32
FRAME_BITS: 64
CHANNELS: 2
RATE: [44100 384000]
PERIOD_TIME: [125 1000000]
PERIOD_SIZE: [8 384000]
PERIOD_BYTES: [64 3072000]
PERIODS: [2 1024]
BUFFER_TIME: (41 2000000]
BUFFER_SIZE: [16 768000]
BUFFER_BYTES: [128 6144000]
TICK_TIME: ALL

[HEnquist]

It's quite unclear what subformat STD really means. In your case, aplay lists STD and MAX as the options. If the device supported any subformat with less than 32 bits, they should be listed explicitly as well. So if the device supported a 24-bit subformat, it should list the MSBITS_24 option. See https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga1e5fe73a6bdf881e2f91921d5e5327c7

Since it is not listed, the most likely scenario is that STD here means the same as MSBITS_MAX, so you get 32 bits in both cases. What do you mean "sounds different", did you measure some different behavior?

[audiofool]

The info I found was on a alsa developers mailing list not sure if it in the current code for alsa - code looked complicated.
What I concerned me in the mailing list was:
S32_LE + STD (maximum bits handled by driver - 24 in this case)
S32_LE + MSBITS_MAX (maximum physical bits for the format - 32)

Definitely sounds different - MSBITS_MAX is brighter and cleaner - I can randomly set it and pick it out every time. No measurements, I may have to try and capture a file through alsa loop. Maybe alsa is trucating to 24 bits within S32_LE.
Why have a STD and MSBITS_MAX option when the only pcm format available is S32_LE?

Thanks again

[HEnquist]

What device is this, and which kernel module is it using? Probably easiest to just look at the source code to figure out what the STD subformat really is here.

Unless there is a problem in the driver, sending 24 and 32 bits should give exactly the same result. A 24-bit device should just ignore the least significant 8 bits.

[audiofool]

Archlinux 6.12.73-1-lts
Advanced Linux Sound Architecture Driver Version k6.12.73-1-lts.

Topping DX1 dac
ak4493 chip
S32_LE

The dac should be using all 32-bits of pcm data, sending 24-bits even dithered can have issues since the internal dithering and upsampling to sdm should be better with 32-bits due to rounding, etc in dac. Heavy noise shaping of even 32-bit seems to sound different - my theory is it overloads the SDM modulator in dac.

Altset2 shown below uses 24-bits but is impossible to access, thankfully alsa seems to always default to the first endpoint Altset 1 at 32 bits instead of altset 2 at 24bits. Choosing STD or MSBITS_MAX does not change the Altset or the S32_LE format.

Playback:
Status: Running
Interface = 1
Altset = 1
Packet Size = 392
Momentary freq = 383996 Hz (0x2f.ffe0)
Feedback Format = 16.16
Interface 1
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 0x01 (1 OUT) (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us
Bits: 32
Channel map: FL FR
Sync Endpoint: 0x81 (1 IN)
Sync EP Interface: 1
Sync EP Altset: 1
Implicit Feedback Mode: No
Interface 1
Altset 2
Format: S32_LE
Channels: 2
Endpoint: 0x01 (1 OUT) (ASYNC)
Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us
Bits: 24

[HEnquist]

Ah I see, it's a USB device. The subformat selection is meant for HD Audio codecs, that want left justified 24-bit data in a 32-bit container. Alsa only defines formats for right justified 24-bit data in 32-bit containers, so therefore they simply hacked their way around this by S32 instead assuming the device will ignore the least significant 8 bits. Setting the subformat to 24 bits allows these devices to be fed "proper" 24-bit data with a zero padding byte.

This doesn't apply to USB devices. Normally 24-bit USB devices use packed 24-bit samples (3 bytes, no padding). This particular device wants 32-bit data for some reason. In this case, the STD means the standard subformat for S32, meaning 32 bits. So it's the same as MSBITS_MAX.

[audiofool]

Thanks for detailed info, makes sense. I hear a difference using aplay --subformat=MSBITS_MAX vs --subformat=STD which shouldn't make a difference with --format=S32_LE. I will look at the aplay source code and post here again if I find anything.
Thanks again.