[vlc-devel] [PATCH V3 2/4] aout: add "audio-bitexact" option

Remi Denis-Courmont remi at remlab.net
Mon Dec 9 21:16:33 CET 2019

Le 2019-12-09 16:20, Thomas Guillem a écrit :
>> If you do bit exact in aout, you don't have a filter chain.

> I could have used a boolean for the "audio-bitexact" option. In that
> case, indeed, there is no need to use a filters chain.
> But what about --audio-bitexact with an aout specific exclusive mode ?

Hmm yeah, what about it?

First off, I am not convinced that we need a core flag at all. It seems 
that the intended semantics are exactly the same as '--audio-filter= 
--resampler=none --no-audio-time-stretch', which means that it already 
works. And I don't think we should go actively out of our way to support 
audiophile nonsense... just tell them how to configure it.

(Actually, it is not so much that audio-time-stretch should be disabled, 
than that the playback rate should be fixed to 1, but I digress.)

> People won't be able to play mp3 with these 2 modes enabled (FL32
> decoder). Is that wanted ? And what about S16N when you have a S24N or
> S32N soundcard ?

Bit exact with a floating point format sounds like an oxymoron. AFAIK, 
auto-proclaimed audiophiles use lossless formats which they expect to 
decode as fixed point.

The discussion is turning in circle now. If the goal is to forcefully 
fail if the audio decoder output _cannot_ be rendered in bit exact mode, 
then we need a boolean flag. But if the goal is merely to minimise 
filtering to necessary conversion, then I don't think we need much 

In any case, I don't see why this needs to be exposed to the filter 
chain; it should be exposed to the owner of the filter chain. And 
conversely, I do see why it should not be exposed there: it's used in 
different contexts some of which should not be affected by aout 

> Using "on"/"off" for "audio-bitexact" seems dubious. That is why I
> would prefer using something like the following:
> --audio-bitexact=0: default
> --audio-bitexact=1: on (with one converter)

Meaning format conversion only? Should only lossless format conversions 
be allowed? What about (mathematically) exact rate-multiple up-sampling 
(8k, 16k, or 24k to 48k, 11025 or 22050 to 44100)? ...

> --audio-bitexact=2: strict (without any converters)
> The big question is: should we remove 1 or 2 ?

Again, I think we should really *not* go out of our way to support this. 
Just make a boolean that refuses to convert and filter if somebody wants 
one. We already have settings to turn filters off, but retain any 
necessary conversions.

Rémi Denis-Courmont

More information about the vlc-devel mailing list