[pulseaudio-tickets] [Bug 93285] New: no fallback when SRB channel fails

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93285

            Bug ID: 93285
           Summary: no fallback when SRB channel fails
           Product: PulseAudio
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: clients
          Assignee: pulseaudio-bugs at lists.freedesktop.org
          Reporter: pierre-bugzilla at ossman.eu
        QA Contact: pulseaudio-bugs at lists.freedesktop.org
                CC: lennart at poettering.net

If a client fails to initialise the SRB channel then it will throw a protocol
error and refuse to continue. This is very undesirable as the SRB channel
requires some glibc and kernel features that the client might not have support
for. The protocol doesn't clearly specify how the client can opt out of SRB
support, except possibly limiting itself to version 29 of the protocol. But
that's not really a long term solution.

Looking at the code, it seems like the server can deal just fine with the
client never ack:ing the PA_COMMAND_ENABLE_SRBCHANNEL. So that's what I've done
in our end for now:

diff --git a/src/pulse/context.c b/src/pulse/context.c
index 738ea84..9566c04 100644
--- a/src/pulse/context.c
+++ b/src/pulse/context.c
@@ -364,7 +364,11 @@ static void handle_srbchannel_memblock(pa_context *c,
pa_memblock *memblock) {
     pa_memblock_ref(memblock);
     sr = pa_srbchannel_new_from_template(c->mainloop, &c->srb_template);
     if (!sr) {
-        pa_context_fail(c, PA_ERR_PROTOCOL);
+        pa_log_warn("Failed to enable SRB channel");
+        c->srb_template.readfd = -1;
+        c->srb_template.writefd = -1;
+        pa_memblock_unref(c->srb_template.memblock);
+        c->srb_template.memblock = NULL;
         return;
     }


Not sure if this is the correct long term approach. A nack in the protocol
would have been nice though.

As to why this happens, we are compiling and shipping our own PulseAudio that
will talk to the local PulseAudio (via tunnel-*-new). But we have to be
compatible with all kinds of old crap out there, so we cannot compile against a
glibc new enough to have eventfd. Hence HAVE_SYS_EVENTFD_H is not set and it
will always fail to create a SRB channel.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20151207/dedea1b5/attachment.html>