Re: Problems with logarithmic volume scaling

Hi Torsten,

> O dear. Total confusion with you :-D
Sorry for that - I'm just a regular user, not an expert on writing multimedia libraries :-) And 
thanks for your patience in explaining all of that and for implementing fixes. I trust that this 
is all we need to get things working. In case of problems I'll get in touch.

Unrelated (?) to the volume scaling itself, I also noticed a weird volume bug when playing music 
tracks (mp3) with this newer version of xine (1.2.13). When playing certain tracks the volume 
lowers itself spontaneously. This isn't reflected in the volume sliders in any way - the music 
just becomes slightly quiter. This doesn't happen for all the songs, but if it happens for a 
certain track then it seems to happen in a deterministic way, i.e. if a track is played from the 
beginning then the volume always gets quiter at the same point in the song. This difference in 
volume is really small, but I know my songs and can hear the difference when using headphones.

Cheers,
Janek

> Lets start over at primal slime.
> All mammal ears (including human ones) roughly are double
> logarithmic - for both pitch and volume. Low values will
> be checked at better resolution than high ones intentionally.
> This is
> a) because of the way ears grow themselves internally, and
> b) because this enables us to evaluate sounds made by
>     creatures in a wide range of sizes. This is quite useful
>     for both hunting and escaping predators.
>
> Linear level handling with mere 200 steps does only cover
> part of our ears capabilities (-40dB .. +6dB), and it also
> delivers less and less audible effect the higher the setting
> goes. Your applications can only fix the latter, at the
> expense of reducing the 200 steps even further effectively.
>
> I will _definitely_ keep the libxine internal logarithmic
> stuff. And I now added a radical user switchable reverse fix
> in form of the new config entry "audio.processing.linear_levels".
>
> https://sourceforge.net/p/xine/xine-lib-1.2/ci/142a16a1dd372a028c6f9bf38220
>964c2ffe10d1/
>
> Yes this does reduce value resolution. However, since the
> filter code in your application followes the same basic idea,
> my reverse filter should not make things much worse there.
>
> This will allow you to adjust libxine to the state of your
> applications without libxine rebuild.
> That is, I still recommend to adjust or remove the application
> side volume/eq value filtere. The dB meanings are well
> documented inside <xine.h>.
> I admit that my #if version test was somewhat stupid.
> You better do a runtime test that does not need application
> rebuild for use with various libxine versions:
>
> int major = 0, minor = 0, sub = 0, value;
> value = myslider_get_value (foo->amp_slider);
> xine_get_version (&major, &minor, &sub);
> if (major * 1000000 + minor * 1000 + sub < 1002013) {
>    value = filter_volume_value (value);
> } else {
>    value = (value * 200 + SLIDER_MAX_VALUE / 2) / SLIDER_MAX_VALUE;
> }
> xine_set_param (foo->stream, XINE_PARAM_AUDIO_AMP_LEVEL, value);
>
> And it also allowes you to live test the difference with
> xine-ui: Open the "settings" window (the panel left lower wrench
> symbol), as well as the audio control window (the panel right
> center 5 sliders symbol). Find "processing.linear_levels" in
> the "audio" tab, click it then "Apply", and play with the
> audio sliders in both settings to hear the difference.
> Remember that those sliders always map to 0..200 directly.
>
> Best regards,
> Torsten
>
> --------
> I am 3 letters ahaed of being an Aviator.