[pulseaudio-tickets] [Bug 44777] module-rtp-send floods the network with UDP packets, crippling it severely

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=44777

--- Comment #9 from Bill McGonigle <bill-freedesktop.org-bugzilla at bfccomputing.com> ---
Created attachment 92370
  --> https://bugs.freedesktop.org/attachment.cgi?id=92370&action=edit
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:

  https://dev.openwrt.org/ticket/10271

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:

  http://wiki.openwrt.org/doc/howto/udp_multicast
  http://www.udpxy.com/index-en.html

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 

  http://wiki.slimdevices.com/index.php/SlimProtoTCPProtocol
  http://wiki.slimdevices.com/index.php/SlimProtoDeveloperGuide
  https://code.google.com/p/squeezelite/source/browse/slimproto.c
  http://wiki.slimdevices.com/index.php/Design_of_new-streaming
  http://wiki.slimdevices.com/index.php/Synchronization

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-bugs/attachments/20140119/f0d664ce/attachment.html>