Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mwillems]

So Pulse Audio theoretically offers the capability of multicasting live audio using RTP in such a way that any computer on the network can play it back (whether using pulse itself, mpd, or even a pipe to aplay).  This sounded like a promising prospect for multi-room sync since you have a master stream/clock, and a few people around the internet had reported success with it.  

JRiver for ARM/Linux can output directly to pulse, so could work as the sound source, etc, and because the playback would be multicast and fully controlled on the server, you could have "dumb" RaspPi clients that just output whatever is coming across the multicast (piped into aplay or something), which would have a super low cpu and memory overhead.  It sounded like a neat way to try and do whole house audio.

So I just did a trial run using configuration steps found in the official documentation:

http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/#index3h2

and also over here:

https://fruit.je/mpd-rtp

I did successfully multicast music, but found RTP completely unusable with any systems using Wi-Fi.  Why?  Because even when the sound server has no sound playing it's constantly hammering the router with thousands of UDP multicast requests, which effectively DOS's the router resulting in a loss of network connectivity for all wireless clients!  To be clear it's not even very much data, it's just the sheer number of UDP packets.

This has apparently been a known pulse bug since at least 2012, and there's no end in sight: https://bugs.freedesktop.org/show_bug.cgi?id=44777#c9

Had I read the bug report linked above, I wouldn't have bothered trying.  In my implementation I saw exactly what the bug reporters saw: as soon as the server went live with the RTP configuration all my wifi connections immediately stopped working.  To be clear, this behavior occurred before I even tried to play any music.  I confirmed it was the pulse server by running tcpdump on various computers around the house.  Wi-fi connectivity only returned once I shut down the machine running the pulse server.

I had active ssh connections to my wi-fi connected clients that immediately stopped responding or lost connections, and even some of my wired connections started getting flaky (weird mouse behavior in VNC, etc.).  Pulse's RTP implementation is just broken and apparently has been for years.

I did successfully play and receive sound from the multicast (on a wired client), and it might be usable for anyone out there with an all wired system, but I don't have enough wired clients to comment on the quality of the sync. Given that it's completely unusable for Wi-Fi, I didn't even bother trying JRiver integration in more depth.  

For everyone else looking for a potential sync implementation, I'd recommend looking somewhere else.  I'd also be curious if anyone here (bob?) has had any luck with pulse's RTP implementation.  It's possible I nerfed the config somehow, but I was using pulse's own reference configuration for this functionality, so I doubt it (especially given the open 3-year-old bug report)

[rozpruwacz]

Hey mwillems,

here is some info about wifi multicast: http://www.wi-fiplanet.com/tutorials/article.php/3433451/Implementing-Wi-Fi-Multicast-Solutions.htm

what about creating separate wifi network only for multiroom devices ? I tested this with one pc (acting as AP) and two laptops. the pc was connected with ethernet to my home network, and using usb wifi adapter (tl-wn-725n) to act as access point to separate wifi network. two laptops were connected to this separate network. with pc acting as a router and as a rtp stream sender I managed to play audio on the laptops over wifi without any delays or interrupts. don't know if it would work for more receivers, but from the lecture of above article a infer that the performance is not affected by the number of receivers.

[mattkhan]

there's an interesting thread on diya on this subject -> http://www.diyaudio.com/forums/pc-based/284528-diy-streaming-audio-thread.html

[mwillems]

there's an interesting thread on diya on this subject -> http://www.diyaudio.com/forums/pc-based/284528-diy-streaming-audio-thread.html

That is quite interesting; I've been following Charlie's posts for a little bit as he's been working out a Linux based audio processor in some other threads.  It sounds like he's got tolerably good sync when it works, but still gets periodic dropouts, which is unfortunate.

what about creating separate wifi network only for multiroom devices ? I tested this with one pc (acting as AP) and two laptops. the pc was connected with ethernet to my home network, and using usb wifi adapter (tl-wn-725n) to act as access point to separate wifi network. two laptops were connected to this separate network. with pc acting as a router and as a rtp stream sender I managed to play audio on the laptops over wifi without any delays or interrupts. don't know if it would work for more receivers, but from the lecture of above article a infer that the performance is not affected by the number of receivers.

Your test case is different than mine in a critical way, so I'm not surprised that you had better results: the device you're using to multicast is also the router!  The issues I saw were a result of the multicasting PC packet flooding my router.  But if the device originating the multicast is also the router, the packet flood problem is non-existent.  I'll have to test and confirm that your solution works here too, but it sounds like a potentially good solution. There are limitations obviously.  You need to have a PC capable of playing media as your router and/or you need to have a way for your endpoints to correctly connect to the "multi-cast" router rather than your normal internet router. 

Thanks for the data points, I've been thinking about building a router for a little bit, and this may influence the design a bit