Bit-Perfect Audio on Linux with PipeWire

[phofman]

And none of it audible unless you want to kill your speakers and shred your eardrums when the real music starts playing.

It certainly is inaudible, but so is a bit(im)perfect chain (digital volume control for 24bit signal, quality resampling). So the question of bitperfection is mostly technical, not practical for listening purposes. Then it either is or is not bitperfect, for a given I/O format.

 

[danadam]

So the lowest bits still generate some signal but not much linearity is left.

JCally JM20 seems to actually truncate to 24 bits because starting from -138.46 dBFS there is no more output.

I had one more point to investigate, which changes conclusions a bit, but I forgot. The thing is that when you simply truncate (instead of round) a small signal, it doesn't become 0, but rather a square switching between 0 and -1. Take for example -139 dBFS:

-139 dBFS, peak ±242: 0x000000f2 - 0xffffff0e

When you truncate this to 24-bits you get:

0x000000 - 0xffffff

All positive values become 0 and all negative values become -1 (in int24 range).

Here is the input signal from earlier:



And manually truncated to 24-bits:



And the recorded signals from earlier:





So looks like only FiiO K3 maybe has some kind of processing of the lowest bits and Adi-2 and Tanchjim Space seem to truncate.

JCallys on the other hand don't truncate but have some detection mechanism and simply ignore too small signals.

And none of it audible unless you want to kill your speakers and shred your eardrums when the real music starts playing.

Yes, it is "perceptually lossless" (as certain codec boasted in the past )

 

[phofman]

The thing is that when you simply truncate (instead of round) a small signal, it doesn't become 0, but rather a square switching between 0 and -1.

So that's 1 LSB error with negative numbers rounding vs. truncation s32 -> s24 , absolutely inaudible.

 

[danadam]

So that's 1 LSB error with negative numbers rounding vs. truncation s32 -> s24 , absolutely inaudible.

Sure, but it shows that a mere presence of the signal on the output is not a sufficient condition to claim whether truncation happened or not.

 

[anonyless]

very thorough interesting guide! this actually pushed me to start using Pipewire on Fedora instead of Pulseaudio (yes I know, it's old) .
this is my current wireplumber conf file with Pipewire, and I get sample rate switching according to the file played on mpv

monitor.alsa.rules = [
{
matches = [ { node.name = "alsa_output.usb-SMSL_SMSL_USB_AUDIO-00.iec958-stereo" } ]
actions = {
update-props = {
audio.allowed-rates = [ 44100 48000 88200 96000 192000 ]
api.alsa.rate = 0
}
}
}
]

I also played a FLAC file I downloaded from Tidal, which is in "MQA encoding (BS)" that normally lights up the blue led on my SMSL PO100 DDC to indicate "Studio MQA quality" (only when the output volume is set to 100%) - and it indeed light up, so I believe i currently getting bit perfect as it is - but i'm going to try making new conf file according to your guide anyway

 

[Jazigo]

only when the output volume is set to 100%

That is cool! Which music player do you use?

 

[anonyless]

That is cool! Which music player do you use?

Feishin , that uses mpv

EDIT: interesting - when playing files with VLC, I see sample rate changes (according to the file) - but not the MQA led turning on when I play that specific FLAC file downloaded from Tidal
EDIT2: i had "audio resampler" turned on in VLC as "automatic" . I guess it's turned on by default. once disabled, MQA led is turning on with VLC playing on the PO100