| Summary: | no fallback when SRB channel fails | ||
|---|---|---|---|
| Product: | PulseAudio | Reporter: | Pierre Ossman <pierre-bugzilla> |
| Component: | clients | Assignee: | pulseaudio-bugs |
| Status: | RESOLVED FIXED | QA Contact: | pulseaudio-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | lennart |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
So you have a client and a server on the same machine, and the server is compiled with eventfd.h and the client is compiled without eventfd.h? I think your workaround is okay for that scenario. I'd probably change the error message to "Failed to create srbchannel from template" just to make it slightly more unique. Want to make a proper git patch out of it and post it to the mailinglist, or should I just grab the diff below and apply it? (In reply to David Henningsson from comment #1) > So you have a client and a server on the same machine, and the server is > compiled with eventfd.h and the client is compiled without eventfd.h? > Yup. > I think your workaround is okay for that scenario. I'd probably change the > error message to "Failed to create srbchannel from template" just to make it > slightly more unique. > > Want to make a proper git patch out of it and post it to the mailinglist, or > should I just grab the diff below and apply it? I'll send it to the list. Committed in 04eb8157533d0ff71cd2a35e8957e43f3e49da83. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.