Problems with logarithmic volume scaling

Janek Stolarek <[email protected]> Thu, 29 Jun 2023 11:35:27 +0200
Newsgroups gmane.comp.video.xine.devel
Message-ID <[email protected]>
Dear xine developers,

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

https://sourceforge.net/p/xine/xine-lib-1.2/ci/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.  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.  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.

We are not sure how to proceed here, since this is a deliberate change in xine and not a bug, 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?

Best regards,
Janek