> On 2010-10-13 18:40, oku at iki.fi wrote: >> From: Jyri Sarha<jyri.sarha at nokia.com> ... > > 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? Yes. On on non real-time OS and having less than accurate audio pipeline latency information this is a best effort task. Making this perfect would require HW support. > > 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? > Since implementing ramps on a HW mixer is really not applicable, this is the only solution that I can see and in practice it seems to work pretty well. I also think that most analog components have enough "slowness" in them which in effect causes a kind of ramp. BTW, ran the test from my previous mail, but using sine wave, and still I could not hear any snapping sound on my T60. > 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 This is pretty much what my patch is doing, just in slightly different order: 1. Insert volume event to happen after sink's reported latency has expired (+ modifications). 2. rewind and adjust volume events 3. wait until volume event expires = rewind margin has passed 4. raise HW volume This approach works also with sinks that do not support rewinding (e.g. alsa-sink not using tsched). > end: > 1) lower HW volume > 2) rewind > 3) write stream with higher SW volume > Here you are forgetting that there may still be some samples left within the rewind margin. You should add the delay also there. In effect the both volume ups and downs become quite symmetrical. > ...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? > Well, I can't think how you get past "wait until rewind margin has passed" without having explicit delays. This code is really only chaning the way HW mixers are used. Ramping to SW volume could be implemented separately and it would not interfere with this patch in fact they would complement each other. But, hey please try out my patch. At least it solved the problem on N900 (yes the earlier version of the patch is on all N900s out there) and it works quite well on my both Linux boxes. Cheers, Jyri
