On Mon, 2011-04-11 at 09:46 +0300, Tanu Kaskinen wrote:
> 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?
I connect with a passthrough stream and I hit this:
Program received signal SIGABRT, Aborted.
0x00007ffff2a96839 in raise (sig=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0 0x00007ffff2a96839 in raise (sig=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff2a97b9a in abort () at abort.c:92
#2 0x00007ffff7b8ea2b in pa_sink_input_assert_ref (i=0x7621e0,
volume=0x7fffffffd5e6, absolute=false) at ./pulsecore/sink-input.h:246
#3 pa_sink_input_get_volume (i=0x7621e0, volume=0x7fffffffd5e6,
absolute=false) at pulsecore/sink-input.c:1219
#4 0x00007fffee451464 in subscribe_callback (c=<value optimized out>,
t=<value optimized out>, idx=<value optimized out>, userdata=0x627ec0)
at modules/module-stream-restore.c:1175
#5 0x00007ffff7b7306e in defer_cb (m=<value optimized out>, de=<value
optimized out>, userdata=0x61d170) at pulsecore/core-subscribe.c:175
#6 0x00007ffff7713e3f in dispatch_defer (m=0x61cf50) at
pulse/mainloop.c:706
#7 pa_mainloop_dispatch (m=0x61cf50) at pulse/mainloop.c:922
#8 0x00007ffff7714165 in pa_mainloop_iterate (m=0x61cf50, block=<value
optimized out>, retval=0x7fffffffdb0c) at pulse/mainloop.c:962
#9 0x00007ffff7714210 in pa_mainloop_run (m=0x61cf50,
retval=0x7fffffffdb0c) at pulse/mainloop.c:977
#10 0x000000000040c440 in main (argc=<value optimized out>, argv=<value
optimized out>) at daemon/main.c:1135
> 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.
Thid does seem to makes sense - modules /will/ have to consider how to
handle the new situations, but that's a good thing.
Cheers,
Arun
