[pulseaudio-discuss] Reverting ade0a6f88464d8aecf83982d400ccfc402341920
gmane at colin.guthr.ie
Fri May 13 08:47:03 PDT 2011
'Twas brillig, and David Henningsson at 13/05/11 16:29 did gyre and gimble:
> On 2011-05-13 09:49, Tanu Kaskinen wrote:
>> Should this commit be reverted?
>> I don't know what problem that commit solves,but it introduces a new
>> problem: if Pulseaudio requests a volume that is above 0dB in the alsa
>> volume element scale, then it can easily happen that alsa will round the
>> request down. That rounding is then compensated with software volume,
>> which in this case is amplification. We don't want software
>> amplification, or do we?
> In short; if we e g have Mic Boost levels at (0dB, 20dB, 40dB and 60dB)
> and the user wants 30 dB, better have 20dB in hardware and +10dB in
> software than 40dB in hardware and -10dB in software, as the latter one
> is more likely to have digital distortion when the signal passes through
> the ADC.
I can see the point in this, but there is still something ultimately
wrong in the logic when dealing with pa_cvolume_divide when calculating
what volume to write to the h/w (this is in an uncommitted patch to add
flat volumes to sources and thus volume controls to source outputs).
By rounding in this direction I find the calculated h/w volume very
sporadic whereby ramping up the volume smoothly in PA will actually
cause the alsa volume to go up and down as it climbs.... e.g. at 72%
alsa was at e.g. +16dB and at 73% it was at +14.5dB which makes no
Perhaps the logic behind using pa_cvolume_divide has not been ported
properly (by me) in my patch, but I think we'll need to look at this
approach a bit to try and work out what's happening and how to fix it.
Tribalogic Limited [http://www.tribalogic.net/]
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss