[vlc-devel] [PATCH V3 2/4] aout: add "audio-bitexact" option
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
More information about the vlc-devel