01-09-2025, 09:17 PM
I implemented 64-bit floating point support mostly because I could with no detrimental effects on any reasonably modern architecture. Raspberry Pi 3 and onwards have direct hardware support. RPi's before it can handle them fine, just a bit slower as they have to process two 32-bit operations instead of one 64-bit one. ALSA's plughw is the only backend I know that can work with 64-bit floating point.
In librespot, the internal processing is in 64-bit floating point regardless of the output format you choose. It's overkill but fun. CamilllaDSP does that too (though you can compile it with 32-bit floating point instead). It really only comes to play when you have a pipeline of signal processing operations. Volume control is also DSP and then there's a lot more you can do in CamillaDSP.
In Deezer I didn't bother and just stayed with 32-bit floating point processing. That already has 1528 dB of dynamic range
Endianness (LE / BE / or native) makes no difference to sound quality whatsoever. Just keep it to what's native (or LE which is native on 99.99% of systems) so your system doesn't need to convert it to another endianness.
My recommendation would be:
First, output mode. Direct (hw) is preferred over Default (plughw) if you can manage without the DSP options.
If you do want to use DSP, don't worry about using plughw, it just costs some a teeny extra bit of CPU for conversions.
Then in Direct (hw) mode: the highest your device supports. S32 > S24 > S24_3 (harder to process) > S16.
In Default (plughw) mode I recommend F64 or F32 as this will give the highest quality input to crossfeed or CamillaDSP, should you use it.
I don't know of any DACs that directly support F32 or F64. Don't think that plughw will fix that: plughw will take F32 or F64, but just convert down to what your DAC is capable of.
In librespot, the internal processing is in 64-bit floating point regardless of the output format you choose. It's overkill but fun. CamilllaDSP does that too (though you can compile it with 32-bit floating point instead). It really only comes to play when you have a pipeline of signal processing operations. Volume control is also DSP and then there's a lot more you can do in CamillaDSP.
In Deezer I didn't bother and just stayed with 32-bit floating point processing. That already has 1528 dB of dynamic range
Endianness (LE / BE / or native) makes no difference to sound quality whatsoever. Just keep it to what's native (or LE which is native on 99.99% of systems) so your system doesn't need to convert it to another endianness.
My recommendation would be:
First, output mode. Direct (hw) is preferred over Default (plughw) if you can manage without the DSP options.
If you do want to use DSP, don't worry about using plughw, it just costs some a teeny extra bit of CPU for conversions.
Then in Direct (hw) mode: the highest your device supports. S32 > S24 > S24_3 (harder to process) > S16.
In Default (plughw) mode I recommend F64 or F32 as this will give the highest quality input to crossfeed or CamillaDSP, should you use it.
I don't know of any DACs that directly support F32 or F64. Don't think that plughw will fix that: plughw will take F32 or F64, but just convert down to what your DAC is capable of.
maintainer of librespot and pleezer
