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

[Jyri Sarha]

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