'Twas brillig, and David Henningsson at 13/05/11 16:29 did gyre and gimble: > On 2011-05-13 09:49, Tanu Kaskinen wrote: >> Hello, >> >> Should this commit be reverted? > > No. > >> http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=ade0a6f88464d8aecf83982d400ccfc402341920 >> >> >> 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 logical sense. 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. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
