<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - module-rtp-send floods the network with UDP packets, crippling it severely" href="https://bugs.freedesktop.org/show_bug.cgi?id=44777#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - module-rtp-send floods the network with UDP packets, crippling it severely" href="https://bugs.freedesktop.org/show_bug.cgi?id=44777">bug 44777</a> from <a class="email" href="mailto:bill-freedesktop.org-bugzilla@bfccomputing.com" title="Bill McGonigle <bill-freedesktop.org-bugzilla@bfccomputing.com>"> Bill McGonigle</a> <pre>Created <a href="attachment.cgi?id=92370" name="attach_92370" title="pcap - load-module module-rtp-send source=rtp.monitor">attachment 92370</a> <a href="attachment.cgi?id=92370&action=edit" title="pcap - load-module module-rtp-send source=rtp.monitor">[details]</a> pcap - load-module module-rtp-send source=rtp.monitor Adding a pcap of the traffic I get when loading module-rtp-send: load-module module-rtp-send source=rtp.monitor and doing nothing more than 'pulseaudio -k'. Jump down past packet 343 where the first SDP capture is, for meaningful wireshark display. It looks like there are two issues here: 1) I presume module-rtp-send shouldn't be sending a constant stream of zero-filled packets just by being loaded with no sources assigned to the sink. That seems really inefficient, especially if sound output is infrequent and/or you have a network with many computers and want to be able to support n-to-n source/sink setups (n number of constant all-zero multicast streams...). 2) I also saw the local WiFi network become crippled by the packet storm. I see in the capture a packet rate of 137 per second. I'm running a -n access point running OpenWRT 12.09 and have a solid 180Mbps+ connection, so I looked into a bit further and found: a) multicast on wireless is effectively useless, or perhaps dangerous. Multicast packets always use the lowest possible data rate on WiFi, which causes them to consume all available bandwidth and crowd out all other traffic: <a href="https://dev.openwrt.org/ticket/10271">https://dev.openwrt.org/ticket/10271</a> It appears that even running multicast on a wired network where wifi access points are connected can cause a takedown of the wifi networks if the wifi access points aren't filtering multicast. b) there are some proposals for fixing this in a later revision of 802.11 but nothing we can use for a long time. c) there are a bunch of people who have tried to use PA with RTP and some Raspberry Pis to distribute music and they've crashed and burned. The Wiki should probably note that this shouldn't be attempted if there's a WiFi network involved. Still, there is strong demand for this use case, if not RTP necessarily.* d) Multicast on WiFi is so bad that it's more efficient to wrap the UDP in TCP and proxy it at the gateway: <a href="http://wiki.openwrt.org/doc/howto/udp_multicast">http://wiki.openwrt.org/doc/howto/udp_multicast</a> <a href="http://www.udpxy.com/index-en.html">http://www.udpxy.com/index-en.html</a> In my testing, igmp snooping on OpenWRT (and presumably all of its derivatives) doesn't work yet. I wonder if supporting udpxy's protocol in PA would make sense for the WiFi use case. Perhaps smarter would be: * there appears to be an evolving open source standard around the SlimProto <a href="http://wiki.slimdevices.com/index.php/SlimProtoTCPProtocol">http://wiki.slimdevices.com/index.php/SlimProtoTCPProtocol</a> <a href="http://wiki.slimdevices.com/index.php/SlimProtoDeveloperGuide">http://wiki.slimdevices.com/index.php/SlimProtoDeveloperGuide</a> <a href="https://code.google.com/p/squeezelite/source/browse/slimproto.c">https://code.google.com/p/squeezelite/source/browse/slimproto.c</a> <a href="http://wiki.slimdevices.com/index.php/Design_of_new-streaming">http://wiki.slimdevices.com/index.php/Design_of_new-streaming</a> <a href="http://wiki.slimdevices.com/index.php/Synchronization">http://wiki.slimdevices.com/index.php/Synchronization</a> and the LMS implementation is said to have excellent synchronization which looks to be handled fairly simply in the perl code. A PA sender and receiver that implemented a subset of squeeze might be neat to have - might even be usable with some of the hardware players. Note: LMS (perl) is GPLv2 but slimsqueeze (c) is GPLv3 so direct code-reuse into PA is probably not possible.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>