Hi, First of all, thanks a lot for pulseaudio, it's wonderful! I have a couple of questions/remarks about the RTP modules. I understand it uses multicast. But when I use it the packets are broadcasted to all hosts in the LAN while I would prefer the packets to be sent only to the hosts that ask for them (those where pulseaudio is running with the module-rtp-recv loaded). This is not so problematic for the wired network, but the packet also get sent to all wifi-connected devices, which is not good at all... Possibly my router is guilty and just implements multicast by mere broadcast. (This is a "freebox revolution", the router from the internet provider named "free" in France.) Or I misunderstood / misconfigured something? I just use IPv4 for now; would IPv6 change something? Is IPv6 supported by the RTP modules? (I must confess I've never played with IPv6, so I'm a bit afraid of setting it up and I prefer to ask before trying it...) Doing experiments, I realised the option 'inhibit_auto_suspend=never' is quite useful in this scenario: UDP packets stop being sent to everyone when I don't play music (In contrast, with the two alternatives, 'always' and 'only_with_non_monitor_sources', the packets continue to flow even if I don't play music...) The sender in my scenario is a headless raspberrybi connected to a hard-drive with the music, and to some reasonably good speakers. The receivers are in other rooms. I usually want the sender to play the music also for itself, so I set the 'loop=true' option and I load the reception module on the sender. This way it works nicely and the music is well synced between the various rooms. (It's not in sync if I send the music directly to the sound-card on this machine, and through RTP for the remote speakers.) I wonder if I loose quality when doing so? I tried to attach the rtp-send module directly to the sink of the sound card rather than to a dedicated null-sink, but it didn't work. Now going back to my problem of having less useless packets on the LAN. Most often I listen to music only from the sender, so that the RTP thing is most often useless, and it's quite frustrating to see all those wasted packets... A hack I tried was to drop the packets in this casual situation, by issuing iptables -A OUTPUT -d 224.0.0.56 -j DROP on the sender; this doesn't save cpu-cycles on the sender, but at least the other hosts on the LAN have a rest until I really want multi-room. But if I do so the sender itself no longer receives the packets... so it doesn't work :( Any idea? Would it make sense to give the possiblity to provide an optional sink to module-rtp-send, to which the data would be pushed directly, in parallel to the UDP packets (respecting the synchronisation of course)? Thanks in advance for your advices, and for the already wonderful software (bluetooth support is great, for instance!) Best, Damien Note: I use pulseaudio 5 from debian/jessie for now ; it's quite old but I had the impression reading the changelogs and the doc that pulseaudio 9 did not change on those aspects. Please tell me if you think it would help.
