>> 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 >
