[pulseaudio-discuss] 2ch -> 6ch upmixing with flatvolumes

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 12/03/11 16:09 did gyre and gimble:
> On Sat, 2011-03-12 at 14:46 +0000, Colin Guthrie wrote:
>> Hi,
>>
>> I was working with Valodim on IRC and stumbled on an issue with flat
>> volumes on 5.1 sinks when playing a 2ch sink input.
>>
>> I try to adjust the Rear left+right to be 0, but it just doesn't let me.
>> It seems the flat volume logic somehow forces it back to the same as the
>> other channels.
> 
> I'm not sure what you mean by "it just doesn't let me". I could try and
> see for myself, but I'm too lazy... I did read some code a bit, and I
> didn't find out what could cause the volume to get stuck in a
> user-visible way. The remapping stuff is a bit complicated to think
> about, though, so I didn't gain confidence that the volume couldn't get
> stuck, either.

Basically I could move the slider in pavucontrol and would look like it
worked but whenever any kind of event that triggered updated sink_info
to be sent, the slider would jump back up to it's original position.

I should look at the pacmd list-sinks output after setting this but I
suspect that it simply doesn't change.

> What I knew beforehand, however, was that if a sink has streams that
> don't have the same channel map as the sink, then the real volume of the
> sink is forced to be "flat" - all channels have the same volume. This
> probably in some way causes the trouble that you're having.

I suspect this is indeed the trouble I'm having :)


> I got the
> impression that you're setting the sink volume in pavucontrol, and the
> sliders would be stuck in some value. When the sink volume is adjusted,
> the reference volume is set before the real volume is calculated, so
> when the real volume is forced to be flat, that shouldn't be visible in
> the GUI (which shows the reference volume).

It's odd, as I saw both scenarios. In the beginning it let me do it, but
after a bout of fiddling, the "sticky" volume problem occured and I
couldn't work out how to change it.

FWIW, this is on a 0.9.22 PA server.

> There's this comment in cvolume_remap_minimal_impact() in sink.c:
> 
>     /* Much like pa_cvolume_remap(), but tries to minimize impact when
>      * mapping from sink input to sink volumes:
>      *
>      * If template is a possible remapping from v it is used instead
>      * of remapping anew.
>      *
>      * If the channel maps don't match we set an all-channel volume on
>      * the sink to ensure that changing a volume on one stream has no
>      * effect that cannot be compensated for in another stream that
>      * does not have the same channel map as the sink. */
> 
> I wonder if that all-channel volume part is really needed. I find the
> current implementation really hard to reason about, but I think forcing
> the real volume to be flat wouldn't be needed at least if the volumes
> were handled a bit differently:
> 
> - Sink inputs would maintain two copies of their volume variables: one
> set of variables for the sink input's channel map and one set for the
> sink's channel map. When a volume variable in either set is updated, the
> corresponding variable in the other set is updated too, using the normal
> remapping function.
> 
> - When the sink has to calculate its real volume from the sink inputs,
> it would look only at the sink input volume that uses the sink's channel
> map. This way there's no need to do do any remapping at this phase -
> each channel of the real volume would simply be set to the maximum found
> in all sink inputs for that channel. There's no way any stream could
> step on some other stream's toes either.
> 
> It would be nice to know what scenario the comment refers to, when it
> says that without that precaution there can be a situation where one
> stream's volume change can't be compensated for in some other stream.


Indeed that sounds like it's the right area. Your suggestions on how to
deal with the volumes certainly sound sensible at first glance but I
wont pretend to fully understand all the volume foo at the moment to
comment more authoritatively :D

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]