About RTP for multi-room

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux