My 16 bit and 24 bit files are now playing back as s32le when checking in pacmd list-sink-inputs.
I have /etc/pulse/daemon.conf configured as s24le as the default bit depth.
Sample Rate is correct and is not being resampled, as I have defined in the pulse daemon.conf.
This is happening on both of my manjaro machines running XFCE. One machine outputs via USB, the other via SPDIF to my Grace Design SDAC .
Previously 16 bit files played at 16 bits, 24 at 24 bit.
Did something change?
If you check in pactl list sinks it will probably show PulseAudio is processing audio with sample-format of 32bits. But response will probably also report that audio device in ALSA only supports bit depth up to 24 bits
alsa.resolution_bits = "24"
PulseAudio may need 32 bit processing to work with other Supported Audio Formats
There is a post on Arch forum from 6 years ago that also identified a similar anomaly
Pulseaudio with USB DAC (FiiO X3 II), DAC reports wrong sample rate - Arch Linux Forums
IMO the best response from that discussion (that was not investigated further) was
only a few drivers use/support S24_LE or S24_3LE
It might be possible to find the hardware sample-format with this command for USB
cat /proc/asound/*/stream0
and this for S/PDIF output from onboard audio
cat /proc/asound/*/pcm*p/sub*/hw_params
(this depth of information is not usually needed for general audio troubleshooting so you might need to look in other files in /proc/asound/ )
Previously 16 bit files played at 16 bits, 24 at 24 bit
You can probably get PulseAudio back to that behaviour if you revert to default configuration setting – default-sample-format s16le
I have setup the bit depth of pulseaudio to s24le, but pacmd list-sinks reports s32le.
Same behaviour like your machines.
PulseAudio configuration option default-sample-format only changes the sample-format used for internal processing and does not affect the bit-depth of the audio stream output to ALSA
PulseAudio is the only major audio package that I know of that still has legacy support for older systems to use sample format of less than 32 bits by default
JACK uses 32 bit sample format by default but has an option to use 16 bit sample format for legacy hardware
-S, --shorts
Try to configure card for 16-bit samples first, only trying
32-bits if unsuccessful. (default: 32-bit samples)
Audacity has a good explanation of the benefits of 32 bit sample-rate processing
Sample Format - Bit Depth - Audacity Manual
The Audacity default quality settings are Sample Format 32-bit float (and Sample Rate 44,100 Hz). It is strongly recommended that you use these settings unless you have good reasons to deviate from these. 32-bit float is chosen to give an extremely low noise floor and to provide good headroom to avoid sound distortion even when performing heavy editing and manipulation of the audio.Audacity uses “float” format for 32-bit recording instead of fixed integer format as normalized floating point values are quicker and easier to process on computers than fixed integer values and allow greater dynamic range to be retained even after editing. This is because intermediate signals during audio processing can have very variable values. If they all get truncated to a fixed integer format, you cannot boost them back up to full scale without losing resolution (that is, without the data becoming less representative of the original than it was before). With floating point, rounding errors during intermediate processing are negligible.
The (theoretically audible) advantage of this is that 32-bit floating point format retains the original noise floor, and does not add noise. For example, with fixed integer data, applying a compressor effect to lower the peaks by 9 dB and separately amplifying back up would cost 9 dB (or more than 2 bits) of signal to noise ratio (SNR). If done with floating point data, the SNR of the peaks remains as good as before (except that the quiet passages are 9 dB louder and so 9 dB noisier due to the noise they had in the first place).