[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