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.
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 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).
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.
--
Tanu
