On Sat, 2011-07-09 at 11:36 +0100, Colin Guthrie wrote:
> 'Twas brillig, and Tanu Kaskinen at 07/07/11 20:42 did gyre and gimble:
> > For the hw volume/mute flags the automation is a bit broken: the hw
> > flags are enabled also for virtual devices that use the volume/mute
> > callbacks for something (like adjusting the output stream volume). Many
> > virtual devices seem to set the hw volume/mute flags explicitly for some
> > reason, so this was broken already before, but for another reason...
>
> Personally I think this is OK. The flags are really misnamed with "HW"
> in them, but really they mean "have volume callbacks". This was how they
> were used before (the asserts made sure of this generally) so I think
> this is acceptable. If you feel strongly about it tho', please do speak
> up and I can reconsider.
No, I don't feel strongly about this.
> >> diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> >> index 45761a6..15c07a5 100644
> >> --- a/src/pulsecore/sink.c
> >> +++ b/src/pulsecore/sink.c
> >> @@ -462,8 +462,19 @@ void pa_sink_put(pa_sink* s) {
> >> pa_assert(s->thread_info.min_latency <= s->thread_info.max_latency);
> >>
> >> /* Generally, flags should be initialized via pa_sink_new(). As a
> >> - * special exception we allow volume related flags to be set
> >> - * between _new() and _put(). */
> >> + * special exception we allow some volume related flags to be set
> >> + * between _new() and _put(). However some are dictated by what
> >> + * callbacks were registered so we set those here.
> >> + *
> >> + * Note: All of these flags set here can change over the life time
> >> + * of the sink. */
> >> + s->flags &= ~(PA_SINK_HW_VOLUME_CTRL|PA_SINK_HW_MUTE_CTRL|PA_SINK_SYNC_VOLUME|PA_SINK_FLAT_VOLUME);
> >
> > This breaks the "force flat volume" feature of module-virtual-sink.
> > Would it do any harm to leave PA_SINK_FLAT_VOLUME out of this list?
>
> So it does. I'll work something out (probably leaving it out and
> duplicating the flat volume flag setting to the alsa-sink/source code,
> but if I can find something that reduces duplication then all the better).
Another thing came to my mind: what about having assertions for checking
that none of PA_SINK_HW_VOLUME_CTRL, PA_SINK_HW_MUTE_CTRL or
PA_SINK_SYNC_VOLUME are set? If the sink implementations can't control
the flags anyway, wouldn't it make sense to prevent them from trying?
--
Tanu
