Re: Problems with logarithmic volume scaling

Hi Janek,

Janek Stolarek <[email protected]>
[xine-devel] Problems with logarithmic volume scaling

 > I'm writing with regards to change in volume scaling introduced
 > in xine-lib 1.2.12, and more specifically in commit
 > 59544d4f4a763bd47a5e8b629e1afc74e0c9a719:

 > This change only recently made it into stable Debian
 > (Debian 11 released in 2021 shipped with xine 1.2.10, recently
 > released Debian 12 ships with xine 1.2.13).
 > I believe this change adversely affects some xine-based applications
 > shipped with Trinity Desktop Environment (TDE) such as Amarok and
 > Kaffeine.

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 :-/
I myself still use a private fork of Kaffeine 1.2.2 with manually
added libxine backend. Even that old version already had dropped
that backend officially.
I use this because of its very good TV GUI, and added quite a few
live TV related patches to libxine.
Nevertheless I havent heard of Kaffeine using xine again so far.

 > For example, lower ranges of the volume scale (say, up to 20%)
 > have practically the same volume, and perceived change in volume
 > between 20% and 50% is smaller than between 60% and 68%.
 > As a result lower range of the volume scale is unusable because
 > it is too quiet, whereas the upper range lacks granularity
 > because changes in volume are too large.

My rotten old Kaffeine simply passes the 0..100% volume setting to
libxine. I found that linear audio scaling not very useful. That
is why I changed to logarihmic mode (with 0 still meaning silence),
an documented this inside <xine.h>.
Works very nice with my Kaffeine :-)

 > This is in contrast with previous linear scaling, where all
 > volume levels were distinct and it was possible to achieve
 > desired volume both in lower and upper ranges of the volume scale.

I guess that your Kaffeine (does it really use xine??) performs
a logarithmic mapping as a workaround on its own, and new libxine
does it a second time. 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

 > We are not sure how to proceed here, since this is a deliberate
 > change in xine and not a bug,

Correct.

 > yet it leads to problematic behaviour in TDE applications.
 > One possible option would be for TDE to maintain its own version
 > of xine with this change reverted, but this sounds like a bad
 > idea.
 > We were wondering if it would be possible for xine to implement
 > a new property, say AO_PROP_AMP_LIN (and corresponding
 > XINE_PARAM_AUDIO_AMP_LEVEL_LIN?) that restores previous linear
 > volume scaling so that the library client can choose between
 > linear and logarithmic volume scaling? Is that something
 > that could happen if we asked nicely?

Logarithmic mode under libxine control only affects
XINE_PARAM_AUDIO_AMP_LEVEL and XINE_PARAM_EQ_*HZ. I will keep the
latter logarithmic because the old linear mode makes audio equalizer
nearly useless. For the former, I added the legacy alternative like
you suggested:

To use, add PLAN B:

#ifdef XINE_PARAM_AUDIO_LIN_AMP_LEVEL
#  undef XINE_PARAM_AUDIO_AMP_LEVEL
#  define XINE_PARAM_AUDIO_AMP_LEVEL XINE_PARAM_AUDIO_LIN_AMP_LEVEL
#endif

to the relevant kaffeine-xbu source file.
This still requires adjusting application code, and it also limits
effective volume value resolution. Again, I think PLAN A is better.

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?

Best regards,
Torsten