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