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.