<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - no fallback when SRB channel fails"
href="https://bugs.freedesktop.org/show_bug.cgi?id=93285">93285</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>no fallback when SRB channel fails
</td>
</tr>
<tr>
<th>Product</th>
<td>PulseAudio
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>clients
</td>
</tr>
<tr>
<th>Assignee</th>
<td>pulseaudio-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>pierre-bugzilla@ossman.eu
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>pulseaudio-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>CC</th>
<td>lennart@poettering.net
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>