Setup: A) PC A (running pulseaudio-6.0-2.fc21.1.x86_64 from Fedora 21) has 5.1 surround output configured, loads module module-native-protocol-tcp and module-zeroconf-publish. B) PC B (running pulseaudio-6.0-2.fc21.1.x86_64 from Fedora 21) has a local sound card (with headphones attached), but normally shall play on PC A. Thus, it loads module-zeroconf-discover. Music is played via Rhythmbox. Zeroconf works fine, and on PC B you're able to switch PulseAudio output to the sink on PC A using the Gnome audio settings. This has worked until a recent update of PulseAudio (version 6?). Until then, it doesn't work anymore and produces these errors on PC A: Apr 21 12:46:46 xxx.lan pulseaudio[1457]: Client sent non-aligned memblock: index 0, length 15928, frame size: 12 Apr 21 12:46:46 xxx.lan pulseaudio[1457]: Client sent non-aligned memblock: index 15928, length 34752, frame size: 12 Apr 21 12:46:46 xxx.lan pulseaudio[1457]: Client sent non-aligned memblock: index 50680, length 5792, frame size: 12 However, when PC A is switched to Stereo instead of 5.1, everything works as expected. Is this a PulseAudio bug or a bug in Rhythmbox? If I can provide additional details, please let me know.
Sounds like a regression, hence marking as a release blocker.
Created attachment 116200 [details] [review] Load new tunnel modules Hi! The attached patch makes module-zeroconf-discover load the new generation of tunnel modules instead of the old generation. I haven't tested it myself, but does it resolve your problem?
(In reply to David Henningsson from comment #2) > Hi! The attached patch makes module-zeroconf-discover load the new > generation of tunnel modules instead of the old generation. I haven't tested > it myself, but does it resolve your problem? Is there a way to find out withour recompiling pulseaudio? So 5.1 should work when not using zeroconf-discover but the direct server name/IP?
(In reply to rh from comment #3) > (In reply to David Henningsson from comment #2) > > Hi! The attached patch makes module-zeroconf-discover load the new > > generation of tunnel modules instead of the old generation. I haven't tested > > it myself, but does it resolve your problem? > > Is there a way to find out withour recompiling pulseaudio? Not sure. I can't reproduce it here, it seems to work with both old and new tunnel modules. > So 5.1 should work when not using zeroconf-discover but the direct server > name/IP? 5.1 should work in all cases (if correctly configured).
I have now tested with default-server-ip and that seems to work. So I guess it's really a zeroconf-discovery problem. If the protocol version is required in zeroconf-publish and it's now being sent, I guess that fixes the issue.
Here's an alternate method that might work for testing. On the client, don't load module-zeroconf-discover when PulseAudio starts up. Instead first run "pacmd set-log-level 4", then run "pactl load-module module-zeroconf-discover". If you know look at your syslog, you should have a line saying 'Loaded "module-tunnel-sink"' and some parameters. Restart pulseaudio and instead of loading module-zerconf-discover, run "pactl load-module module-tunnel-sink <parameters>", where you copy the parameters found in your syslog. If you can now reproduce the "non-aligned memblock" bug, then you should be able to redo the test but with the module-tunnel-sink-new module instead. That said, I can't reproduce the bug here even with the old module with a 5.1 configuration, so it's a bit of a mystery to me how it can appear.
Thanks for your instructions. My new findings (both pulseaudio-6.0-2.fc22.x86_64): 1) WITH DEFAULT-SERVER When using default-server = <name-of-pc.lan> instead of zeroconf-publish/discover on PC B, 5.1 sound transmission to PC A works perfectly. There are no suspicious log messages, neither on PC A nor on PC B. However, when using this configuration, I can't switch to the local headphones on PC-B in Gnome audio settings because the local sound card is not used by pulseaudio. 2) WHEN ADDING THE SINK MANUALLY WITH PARAMETERS AS TOLD BY zeroconf-discover When following your instructions, zeroconf-discover reports this sink (+ another HDMI sink which I won't use): server=[<ip of PC A>]:4713 sink=alsa_output.pci-0000_00_1b.0.analog-surround-51 format=s16le channels=6 rate=44100 sink_name=tunnel.PC-A.local.alsa_output.pci-0000_00_1b.0.analog-surround-51 channel_map=front-left,front-right,rear-left,rear-right,front-center,lfe When adding this on PC B with "pactl load-module module-tunnel-sink", pactl prints "24". I don't even have to play something: immediately after adding the sink on PC B, PC A prints these lines to the logs: --------------------------- Jun 10 21:23:38 PC-A.lan pulseaudio[3268]: [pulseaudio] protocol-native.c: Client sent non-aligned memblock: index 0, length 18824, frame size: 12 Jun 10 21:23:38 PC-A.lan pulseaudio[3268]: [pulseaudio] protocol-native.c: Client sent non-aligned memblock: index 18824, length 17376, frame size: 12 --------------------------- The memblock indexes and the count of these lines vary when I try several times. Now the strange thing: When using "module-tunnel-sink-new", the same lines appear and it doesn't work, either. 3) WITHOUT ADDING A SINK MANUALLY, BUT USING paplay Now the even more strange thing: When using "paplay -v -s PC-A.lan some-stereo-sample.wav", all works: --------------------------- Opening a playback stream with sample specification 's16le 2ch 44100Hz' and channel map 'front-left,front-right'. Connection established. Stream successfully created. Buffer metrics: maxlength=4194304, tlength=352800, prebuf=349276, minreq=3528 Using sample spec 's16le 2ch 44100Hz', channel map 'front-left,front-right'. Connected to device alsa_output.pci-0000_00_1b.0.analog-surround-51 (index: 1, suspended: no). Stream started. Stream underrun. Playback stream drained.: 382721 usec. Draining connection to server. --------------------------- When playing a 5.1 sample WAV file, it does NOT work: --------------------------- LANG=en paplay -s pc-a.lan -v 6_Channel_ID.wav Opening a playback stream with sample specification 's16le 6ch 44100Hz' and channel map 'front-left,front-right,front-center,lfe,rear-left,rear-right'. Connection established. Stream successfully created. Buffer metrics: maxlength=4194312, tlength=1058400, prebuf=1047828, minreq=10584 Using sample spec 's16le 6ch 44100Hz', channel map 'front-left,front-right,front-center,lfe,rear-left,rear-right'. Connected to device alsa_output.pci-0000_00_1b.0.analog-surround-51 (index: 1, suspended: no). <<gets stucked here until I hit Ctrl+C>> ^CGot signal, exiting.cy: 666643 usec. --------------------------- (on PC A, the non-aligned memblocks are printed) So I guess this must be somehow related to how 5.1 sound is transmitted. Does this make any sense to you? Can I do more debugging, maybe with paplay?
I initially thought this was something related to the tunnel module, but now that I've thought some more about it and seen the result of your last experiments, I think the bug is already fixed upstream, by this commit: commit 7b8e8cd3883e081a6e3f2d8ed307524801438e04 Author: David Henningsson <david.henningsson@canonical.com> Date: Thu Mar 5 14:55:51 2015 +0100 pstream: Don't split (non-SHM) memblocks Because you're using 6.0 and I'm using latest git head, that's why it crashes for you and not for me. And that seems to be approximately where things could go wrong. There are still mysteries though, as why and how this regressed from a previous release, and also, why the mcalign layer does not fix it up. Anyhow, is there any chance you can test git head to see if the bug is fixed? It's the receiver side (i e the one that prints the "non-aligned memblock" error) that needs updating.
Thanks for your information. I have tried with latest pulseaudio from git on PC A and it's now working. I'll ask the Fedora package maintainer whether (s)he can publish a version where this issue is fixed to Fedora-updates.
Cool, thanks for testing!
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.