[pulseaudio-discuss] [PATCH 0/5] HW and SW volume syncronization in IO-thread

[David Henningsson]

On 2010-10-13 18:40, oku at iki.fi wrote:
> From: Jyri Sarha<jyri.sarha at nokia.com>
>
> The first patch in the set gives sink implementor a possibility to
> synchronize HW and SW volume usage in IO-thread. The remaining patches
> implement the synchronization for the alsa-sink and add the necessary
> module parameters and defaults for them in daemon configuration.
>
> This code has been tested on Nokia's ARM based Meego platform, on i686
> laptop and on amd64 desktop. Tanu Kaskinen has also reviewed the code.
>
> To check what this set of patches does, please try following:
>
> 1. play white noise in background on low volume:
> # pacat --fix-rate --volume=10000<  /dev/urandom
>
> 2. play a short transient stream with high volume while the noise
>     plays in background:
> # dd if=/dev/zero count=200 | pacat --fix-rate --volume=65536
>
> Without these patches on most hardware you hear an annoying snap
> either in the beginning or the end (sometimes both) of the transient
> stream.After applying the patch the snap should be gone or at least
> less audible. With a little fiddling of the parameters it should be
> possible to get rid of the snap on all hardware. The default
> parameters work well at least on my Lenovo T60 running Debian Squeeze
> and they should be good, maybe a bit conservative, for most HW out
> there.
>
> This patch is pretty much mandatory for proper usage of flat volume
> especially on less powerful HW.

Thank you for your work! This is the main reason I've been advocating 
against enabling flat-volumes by default in Ubuntu, so I'm glad to see 
something that addresses the issue.

The basic problem is that we can't have sample accurate volume changes, 
because no HW supports it. Right?

So about the implementation - what you're saying is that it is better to 
have two guaranteed down-volume "snaps" rather than to risk an up-volume 
"snap". That sounds reasonable, but are these down-volume transients 
hearable? Perhaps more hearable with playing a sine wave, rather than 
white noise?

Anyway, I've been thinking of something like this but never looked more 
closely at implementing a solution, but I would probably have tried to 
do something like:
start:
  1) rewind
  2) write stream with lower SW volume
  3) wait until rewind margin has passed
  4) raise HW volume
end:
  1) lower HW volume
  2) rewind
  3) write stream with higher SW volume

...rather than trying to add explicit delays just for the volume sync. 
Either that, or some kind of volume ramping. Just curious if you 
considered that solution as well?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic