On 2010-10-13 18:40, o...@iki.fi wrote:
From: Jyri Sarha<jyri.sa...@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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
