Bug 86065

Summary: volume changes rounded to increments of ~3%
Product: [Applications] kmix Reporter: Luke <lcampagn>
Component: generalAssignee: Christian Esken <esken>
Status: RESOLVED NOT A BUG    
Severity: normal    
Priority: NOR    
Version First Reported In: 2.0.1   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Luke 2004-07-27 03:48:37 UTC 
Version:           2.0.1 (using KDE 3.2.3,  (testing/unstable))
Compiler:          gcc version 3.3.3 (Debian 20040422)
OS:                Linux (i686) release 2.6.7

Requests to kmix to alter a volume control yield somewhat unpredictable results on my system--the volume usually ends up within 2 or 3% of the expected value. For instance, increasing 10% from 50% might set the volume to 58% or 63%, rather than 60 exactly. This gets even worse if you try to change by very small increments; 1% changes are almost always just ignored. 

It is behaving as if there are only about 30 steps in the entire volume range, and changes are just rounded to the nearest step. I first noticed this using kmilo, and then confirmed it using dcop on the command line.
Comment 1 Tom 2004-09-15 19:45:54 UTC 
There are, in fact, only 32 steps (0-31) in the entire volume range for most soundcards.  ALSA at least exposes this, OSS may have hidden it, I'm not sure.  The only real bug, I think, is that 1% changes sometimes have no effect - they should change the volume by the minimum of 1% and 1 notch.
Comment 2 Christian Esken 2004-11-20 15:44:36 UTC 
It is, in fact, exactly as Tom described. It is a hardware limitiation (and it is exposed by ALSA), so this is correct behaviour.
KMix cannot be more precise than your hardware.
So I'll close this bug report.

Greetings,
  Chris