[vlc-devel] [PATCH V3 2/4] aout: add "audio-bitexact" option
thomas at gllm.fr
Tue Dec 10 15:10:29 CET 2019
On Mon, Dec 9, 2019, at 21:16, Remi Denis-Courmont wrote:
> 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
Thanks for this very complete answer.
I didn't know we could already disable the resampler. I will make audio-bitexact a bool and fully disable the filters chain if enabled. Indeed, --audio-bitexact=convert was just like --audio-filter=none --audio-resampler=none --no-audio-time-stretch.
> > 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
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel