On 28.07.2016 16:42, Damien wrote: > 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...) You need to have IGMP snooping enabled on your switch to prevent packets going to destinations that have not subscribed to the multicast stream. > > 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 Maybe it helps if you exclude the loopback interface (not sure if the multicast is received on the loopback however): iptables -A OUTPUT -d 224.0.0.56 ! -o lo -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. > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
