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

[Steve Lhomme]

On 2019-12-09 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 
> anything?
> 
> 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 settings.
> 
>> 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)? ...

I think there's even 2 kinds of conversions, the lossless ones and the 
lossy ones (24 bits to 16 bits soundcard). Given the name 
"audio-bitexact" the lossy ones should probably not be allowed or only 
in the most permissive mode (0=default=off).

>> --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:
> https://mailman.videolan.org/listinfo/vlc-devel