Re: Problems with logarithmic volume scaling

Hi Torsten,

thanks for your reply.

> As far as I know, the outside world (most notably Kaffeine) has
> stopped using libxine a long time ago, because of lots of bugs
> and missing features back then :-/
Kaffeine and Amarok that I'm referring to are part of Trinity Desktop Environment, which itself is 
derived directly from KDE3. It is in fact KDE3 which got rebranded and is maintained, developed, 
and released for modern Linux distributions to this day. And it does indeed use xine, just like 
in KDE3 days. More information here:

https://www.trinitydesktop.org/

I shall also clarify here that, although I say "we" and "us" a lot when referring to the TDE 
developers team, I myself am just a bug reporter and translator, so I'm not directly involved in 
code development.

> I guess that your Kaffeine (does it really use xine??) performs
> a logarithmic mapping as a workaround on its own
I believe it does not use logaritmic mapping. Here is how Kaffeine sets volume:

https://mirror.git.trinitydesktop.org/gitea/TDE/kaffeine/src/branch/master/kaffeine/src/player-parts/xine-part/kxinewidget.cpp#L2670

And here is how Amarok does it:

https://mirror.git.trinitydesktop.org/gitea/TDE/amarok/src/branch/master/amarok/src/engine/xine/xine-engine.cpp#L577

(Note: for me Amarok is the more important use case, since that's what I use daily.)

> The best solution would be to limit the volume kludge inside Kaffeine to PLAN A:
>
> #if (XINE_MAJOR_VERSION * 10000 + XINE_MINOR_VERSION * 100 +
> XINE_SUB_VERSION < 10213)
> ...
> #endif
Sorry, I'm not sure if I understood what you tried to say here. Do you mean that we could 
implement different volume scaling logic for different xine versions?

> Logarithmic mode under libxine control only affects
> XINE_PARAM_AUDIO_AMP_LEVEL and XINE_PARAM_EQ_*HZ.
To set the volume Amarok uses the former, as witnessed by source code links provided above. And 
then it uses the latter for the equalizer:

https://mirror.git.trinitydesktop.org/gitea/TDE/amarok/src/branch/master/amarok/src/engine/xine/xine-engine.cpp#L655

> I will keep the latter logarithmic because the old linear mode makes audio equalizer
> nearly useless.
Hm... this bit is interesting. I've been using Amarok for the past two decades, always with my 
custom equalizer settings, and I always found it to work as expected. Can you clarify on 
the "nearly useless" bit?

> For the former, I added the legacy alternative like you suggested.
Thanks. Just looked at your latest commit and I admit I don't entirely follow the logic. Does it 
restore the exact same logic as before? Is that an inverse of logaritmic scaling?

> This still requires adjusting application code, and it also limits
> effective volume value resolution.
Can you elaborate on this? Adjusting application code is fine - it can be done by the TDE team. 
I'm concerned about what you said about limited volume value resolution. This is one of the 
problems we want to solve here.

> I could also add a new config option or a XINE_PARAM to switch
> behaviour, but that would break transparent enhancement of old
> applications like gxine, or my old Kaffeine.
>
> What do you think?
I think an ideal solution would be one where:
1. There exist XINE_PARAMs that implement old behaviour exactly as it was, 1-to-1.
2. We can then use those new params to restore the old behaviour.

The best solution I could imagine is one where all parameters revert to their old behaviour, and 
then you add logaritmic volume scaling to use with your private Kaffeine. I realise this is an 
egoistic request, so adding new XINE_PARAMs (also for equalizer) would be fine. This would incur 
some extra work on our side, but that is manageable.

Of course we will still face problems with library versions. Firstly, TDE maintains builds for 
Debian oldstable (one that shipps with xine-1.2.10) so we need to add conditional compilation and 
act accordingly - your PLAN B looks like it would do the job here. Secondly, stable Debian just 
shipped so the new stable release will not ship anytime soon, meaning we'll either be stuck on 
xine-1.2.13 for the next few years or somehow ship it with TDE. But that is for us to figure out.

Once again thank you for your help!

Best regards,
Janek