[pulseaudio-discuss] [PATCH] sink-input: Don't assert while trying to get non-readable volume

Tanu Kaskinen tanuk at iki.fi
Sun Apr 10 23:46:30 PDT 2011

On Sun, 2011-04-10 at 16:52 +0530, Arun Raghavan wrote:
> Since no clients currently handle non-readable volumes, we handle this
> condition more gracefully (return PA_VOLUME_NORM). In the future, this
> could probably changed into an error return instead of an assert so that
> a non-conformant client doesn't bring the daemon down.

When I added the assertion, the idea was that whatever code calls
pa_sink_input_get_volume() calls first
pa_sink_input_is_volume_readable(). And I at least tried to add those
checks everywhere. How are you able to hit the assertion?

My current plan for non-readable volume is a slightly different, btw.
Instead of having a volume_readable property, I plan to have a
volume_enabled property. When volume_enabled is false, within the daemon
the volume is still readable and writable (unless volume_writable is
false), it just doesn't have any effect. This gets rid of the problem of
how to restore the old volume after the volume is re-enabled when
switching between passthrough and normal modes. To the clients this is
not a very visible change - they still can not read (or they get always
PA_VOLUME_NORM as the value) or write the sink volume when it's in the
passthrough mode. But this behavior is implemented within
protocol-native etc, not enforced by the core.


More information about the pulseaudio-discuss mailing list