eric.frederich
Posts: 11
Joined: Tue Oct 11, 2011 11:53 am

Multi-room audio solution

Fri Dec 14, 2012 5:37 pm

I ordered 2 Model B raspberry Pi's.
I want to use them to power bookshelf speakers in my living room and dining room.
If it turns out well, I'd get more and have them in nearly every room in the house.

What is the best solution for this?

Ideally I'd like to interact with it via Android.

Is SqueezeBox really the way to go? I have heard that Logitech may be abandoning squeezebox in the near future in favor of its new UE platform.
http://reviews.cnet.com/8301-33199_7-57 ... hats-next/

Are there any PulseAudio based solutions for this? I think that was one supposed to be one of PulseAudio's strongpoints.... setting up dumb audio sinks.

ianmacs
Posts: 31
Joined: Mon Jul 09, 2012 10:42 am

Re: Multi-room audio solution

Sat Dec 15, 2012 1:12 am

For the multi-room audio system that I want to install in my next home, I have experimented using two raspberry pis so far. Results look good, so I have ordered 4 more pis. The preliminary plan follows:

Network:

A central switch, Cat6 ethernet cable in the walls, multiple RJ45 sockets in every room. All pis synchronize their clocks via ntp with a local ntp server to achieve simultaneous playback without noticeable echo. All audio traffic travels on wires, only controlling devices may be attached wirelessly.

Library:

One of the pis will serve the media library. The library lives on an external USB drive that spins down automatically when not in use. The media library is made accessible using samba and minidlna.

Zone broadcasters:

The zone broadcasters are pis which recieve content from the library, decode the audio to PCM and broadcast the PCM data to the whole home using UDP multicast.

For the broadcasting software, I decided on pulseaudio's RTP mechanism. While it is possible to configure pulseaudio so that one pi broadcasts different streams to multiple zones simultaneously, I learned that audio decoding is one of the likely bottlenecks and can use slightly >50% CPU of the pi. Therefore, I currently plan to use 4 pis to broadcast to 4 respective virtual playback zones, blue, green, yellow, red. Network-wise, the different zones correspond to different multicast addresses.

For the software to decode the library content on the broadcasters, any remotely controllable media player will do. I am leaning towards mpd and gmediarenderer (this https://github.com/hzeller/gmrender-resurrect fork works well on the pi). One of them would be sufficient, But why not install both and see how it works out. For both, a ton of front-ends is available.

Receivers:

Receivers are Pis running pulseaudio with rtp receiver modules. They convert the Multicast RTP PCM stream into analogue audio which is played back using active speakers or a stereo system connected to the pi. 2 important non-default pulseaudio configurations: module-suspend-on-idle causes crackling on the pi between songs, avoid loading this module. The default resampling method speex-float-3 does not work on the pi with the adaptive resampling required to compensate for the clock drift between rtp stream and alsa device. I choose src-sinc-fastest.

Each receiver has a zone chooser attached to GPIO pins. Pressing the appropriately colored button causes the receiver to tune into that zone and render it through the attached speakers.

Receiving takes 30 % CPU, therefore, a receiver may simultaneously function as a zone broadcaster.

Broadcast controllers:

Broadcast controllers control the broadcasting software, i.e. which song is running in which zone. Android devices with bubbleupnp and mpdroid can be used for this purpose. More front ends will have to be evaluated.

Extensions:

A pi connected to the TV might be used to digitize and broadcast the TV sound, and also serve as a raspbmc media center for video playback.

Comments and suggestions welcome

MeMike
Posts: 11
Joined: Sat Dec 15, 2012 3:13 am

Re: Multi-room audio solution

Sat Dec 15, 2012 3:54 am

ianmacs, I'm looking at a similar solution. Dedicated broadcast server running MPD and pulseaudio (no audio on server) with SAMBA share (also on server) for music storage. (SAMBA as the storage is also used for other PC's (Windows) in the house.) I'm looking to have one source/multiple outs.

MPD is mature and clients are available for most devices (i?, PC, Mac, android)
I attempted icecast to start but synchronization among the receivers was just plain .... (enough said)

RPi as receivers with PCM2704 USB DAC for audio (Coax/TosLink and headphone) out . (See [http://www.raspberrypi.org/phpBB3/viewt ... 38&t=20866] for details - works very well.

1x RPi to stereo (TosLink)
2x RPi to active speakers

Control Client for MPD is either Droid MPD Client HD Free (Android) or Auremo (Windows).
Running Chrony for time synchronization (Better for non-full time connected computers)

Still working on the set up. Fighting pulseaudio (no decent manual) and alsa (w/o resorting to X). I'm running pulse as system-wide (yourself?) on server and Rpis.

Interesting comment on speex-float-3 - Thanx.
I'm also a semi-noob for linux....

I like your setup. Any further comments would be appreciated. Could you send me your pulse/alsa config files.

Eric, my research (for what it's worth) went to this solution. LMS and squeezeslave didn't have the flexibility of the MPD/PulseAudio solution. Now that I know someone has done it on the Rpi hardware, I'm even more sure. An inexpensive SONOS.

Mike G.

ianmacs
Posts: 31
Joined: Mon Jul 09, 2012 10:42 am

Re: Multi-room audio solution

Sat Dec 15, 2012 2:51 pm

MeMike wrote:Dedicated broadcast server running MPD and pulseaudio (no audio on server) with SAMBA share (also on server) for music storage. (SAMBA as the storage is also used for other PC's (Windows) in the house.)
I take it your server is not a pi. I found that serving samba and running mpd on the same pi is too much and causes pauses. I think cpu is the limiting factor, not the network, but you should have an eye on that and if you experience dropouts, you should separate the two tasks to different machines.
I'm looking to have one source/multiple outs.
Only a single Zone in my picture. That's all I have so far, so I can give you configurations for that.
I attempted icecast to start but synchronization among the receivers was just plain .... (enough said)
Pulseaudio's RTP works fine so far. Initially, I had to set sync the times manually using ntpdate, since the ntp daemon would take too long to sync. Still there is a noticeable delay: Starting, pausing, adjusting volume using an mpd controller, and I have to wait almost 1 second for the change to take effect in the renceivers. But since the delay is exactly the same for all receivers, I can live with that.

Note that receivers still can get out of sync under heavy load when using RTP, e.g. when simultaneously applying software updates. This should not be an issue for a dedicated installation. Restarting pulseaudio helps.

Also note that there exists a different pulseaudio network mechanism, using TCP. That mechanism causes sync differences of up to 1 second. So better use RTP, which additionally can multicast.
RPi as receivers with PCM2704 USB DAC for audio (Coax/TosLink and headphone) out . (See [http://www.raspberrypi.org/phpBB3/viewt ... 38&t=20866] for details - works very well.
Yes I have read this thread, but when I remove the crackling between songs by using pulseaudio without the module-suspend-on-idle, the sound quality of the Pi with current firmware is good enough for me. Also, considering that USB is still buggy on the pi, Ethernet is already connected via USB, and in that very thread people have reported that their pi loses network connection when using a USB sound card, I'd refrain from relying on USB sound cards for now. Of course, for digitizing TV sound, I would need a USB sound card, but this is only an optional extension for later.
Running Chrony for time synchronization (Better for non-full time connected computers)
Interesting, have not heard about it before. Thanks for the suggestion.
Fighting pulseaudio
I can relate. I fought more than a month with pulseaudio until christian http://www.raspberrypi.org/phpBB3/viewt ... 50#p230350 identified the resampling as the culprit.
I'm running pulse as system-wide (yourself?) on server and Rpis.
Yes, system mode.
Could you send me your pulse/alsa config files.
Configuration overview:

I use raspbian. The next changes to the default configs apply to both, broadcasters and receivers.
To start pulseaudio in system mode, change one line in /etc/default/pulseaudio to

Code: Select all

PULSEAUDIO_SYSTEM_START=1
I also modified some command line parameters in /etc/init.d/pulseaudio, the relevant line in pulseaudio_start() now reads

Code: Select all

        start-stop-daemon -x $DAEMON -p $PIDFILE --start -- --system --log-level=4 --disallow-exit --disallow-module-loading=$DISALLOW_MODULE_LOADING --daemonize --log-target=syslog --realtime
, which increases verbosity of logging (to /var/log/syslog) and tries to get realtime priority.
I plan to decrease verbosity again when the installation is final.

I prepended a # sign to the line

Code: Select all

#load-module module-suspend-on-idle
in /etc/pulse/system.pa so that this module is not loaded.

The following change applies to bradcasting pis.

Appended the following lines to the file /etc/pulse/system.pa on the pi broadcasting to the blue zone:

Code: Select all

load-module module-null-sink sink_name=rtp_blau format=s16be channels=2
load-module module-rtp-send source=rtp_blau.monitor
This sends rtp to pulseaudio's default multicast address, 224.0.0.56. To send to another zone, change the names as needed an append

Code: Select all

destination=224.0.0.57
to the line loading module-rtp-send.

The following changes apply to receiving pis:
Append the line

Code: Select all

load-module module-rtp-recv
to file /etc/pulse/system.pa. Again, this will catch packets arriving on pulseaudio's default multicast address 224.0.0.56. To listen to a different zone, append a parameter like

Code: Select all

sap_address=224.0.0.57
.

I have not fully figured out how zone switching in receivers would work. I think receiving all 4 streams simultaneously and selecting by volume is too expensive. Maybe there is a way to reload pulseaudio modules even in system mode. Otherwise, it should be possible to relay arriving multicast RDP packages to a local address, and reconfigure the relay. The relay may be implemented as a user process or as a set of iptables rules.

Additionally, on receiving pis, I appended to /etc/pulse/daemon.conf:

Code: Select all

default-sample-rate = 48000
resample-method = src-sinc-fastest
default-fragments = 10                                                
default-fragment-size-msec = 10
I prefer 48 kHz for two reasons:
- the alsa driver on the pi will only interrupt at a multiple of full 10 ms. On the other hand, allowed period sizes are multiples of four. This leads to timing jitter in interrupt frequency when you use 44.1 kHz (even in the case of using a period size of 4 times * 441, which is mysterious, but that's what I saw when experimenting with alsa on the pi). The pulseaudio rtp receiver can do a better drift control without this unnecessary timing jitter.
- the inevitable clock drift between unsynchronized sample clocks requires adaptive resampling in the RTP receiver, regardless of whether the nominal sampling frequencies are the same or differ. I expect worse resampling artifacts when the nominal sampling frequencies are the same.

If you want to experiment with the other setings, observe the following conditions: default-fragment-size-msec should be a multiple of 10, else you would again get unnecessary jitter in interrupt callbacks. The product of default-fragment-size-msec and default-fragments should correspond to 8192 samples or fewer, as 8192 samples is the maximum buffer size allowed by the pi's alsa driver.

Comments welcome.

MeMike
Posts: 11
Joined: Sat Dec 15, 2012 3:13 am

Re: Multi-room audio solution

Sat Dec 15, 2012 5:17 pm

ianmacs: thanx for the reply and configuration suggestions.
I take it your server is not a pi. I found that serving samba and running mpd on the same pi is too much and causes pauses. I think cpu is the limiting factor, not the network, but you should have an eye on that and if you experience dropouts, you should separate the two tasks to different machines.
I'm using a hacked HP MediaSmart Server (Fedora 17) Assumed the RPi didn't have the power plus wanted Raid for the music collection.
Also note that there exists a different pulseaudio network mechanism, using TCP. That mechanism causes sync differences of up to 1 second. So better use RTP, which additionally can multicast.
Couldn't agree more.

Pulseaudio needs some better explanations, I think I would have spent an other rmonth without your suggestions, and probably given up in frustration.

Thanx for the tips on.
load-module module-suspend-on-idle
resample-method <-- Would have never thought of this
default-fragments = 10
default-fragment-size-msec = 10


It all works now....
Now to build the cases and see how it works with wifi (WAF)
Thanx for the assistance....

Mike G.

ianmacs
Posts: 31
Joined: Mon Jul 09, 2012 10:42 am

Re: Multi-room audio solution

Sat Dec 15, 2012 8:52 pm

Forgot to report the mpd configuration to have it stream using RTP:

Code: Select all

audio_output {
    type            "pulse"
    name            "MPD Stream blau"
    sink            "rtp_blau"
    description     "what's playing in the blue zone"
    mixer_type      "software"
}
Adapt as needed, see example pulseaudio configuration from my previous post.

s7mx1
Posts: 78
Joined: Fri Sep 30, 2011 9:28 am

Re: Multi-room audio solution

Sat Dec 15, 2012 11:38 pm

RTP broadcast looks good on paper but does not always work especially on wifi network (router hardware,software etc). The module-tunnel-sink works really well and I can get low latency less around 200ms over wifi using TCP.

I have a script running at background to check the availability of the destination pulseaudio server and if its available will check the supported format and add it accordingly.

Pulseaudio 2.0 and above has introduced alternative sample rate which means it will try to switch the hardware to match the sample rate of the audio to avoid resample if possible. Personally I would avoid using resample and this means matching source sample rate with hardware's.

I won't be bothered with anything other than "ffmpeg" for resample-method.

If you want to fine tune the pulseaudio latency you can try

default-fragments = 8
default-fragment-size-msec = 10


I was working on firwmare mod to turn tiny small router (with usb sound card) into pulseaudio server, this should work perfectly in this multiroom situation as it does come with wifi chip and has less problem with the usb port.

ianmacs
Posts: 31
Joined: Mon Jul 09, 2012 10:42 am

Re: Multi-room audio solution

Sun Dec 16, 2012 12:37 pm

s7mx1 wrote:RTP broadcast looks good on paper but does not always work especially on wifi network (router hardware,software etc). The module-tunnel-sink works really well and I can get low latency less around 200ms over wifi using TCP.
Hi Steve, at least for me, multi-room audio is not so much a question of latency, but rather of synchrony. Pulseaudio's RTP receiver does this well. You may be correct about possible package loss when using wireless. Mike will have to test for this.

As I wrote, I tested module-tunnel-sink and observed asynchrony of up to 1 second time difference between different pi reveivers. (A third computer acted as the sender, using module-combine to combine two module-tunnel-sinks sending to the pis, so I'm not talking about sender-receiver latency, but about synchrony between receivers)

Currently, I know only 3 IP-based audio distribution systems that can achieve synchrony between different receivers, these are RTP (when the receiver does this right), Netjack, and Ravenna http://ravenna.alcnetworx.com/technolog ... venna.html, which is also RTP based, but also makes use of PTP (precision time protocol), while RTP synchrony as implemented in pulseaudio relies on host clock synchrony which can be achieved with NTP.

Netjack does not run on the pi because jackd relies on the MMAP alsa access mode, which the pi's alsa driver does not provide. As soon as that is solved, I'd like to try out netjack.

Ravenna is in its infancy and looks like a nightmare to set up. I did not even try.
I have a script running at background to check the availability of the destination pulseaudio server and if its available will check the supported format and add it accordingly.
You write "destination pulseaudio server" in singular, and you do not mention module-combine, which would be necessary for a multi-room audio solution based on module-tunnel-sink. Are you sure you are talking about the same thing?
Pulseaudio 2.0 and above has introduced alternative sample rate which means it will try to switch the hardware to match the sample rate of the audio to avoid resample if possible.
This would again introduce the loud crackling on the pi's analogue out.

s7mx1
Posts: 78
Joined: Fri Sep 30, 2011 9:28 am

Re: Multi-room audio solution

Sun Dec 16, 2012 7:02 pm

It's all about latency, because of uneven latency introduced in your particular setup you will hear out of sync sound produced on different pi. You could make it much simpler.

MPD can do multiple outputs at run time. If you have ever used any decent mpd app (I tried android one) which will let you choose which sound output you want to enable or disable when music is playing. That way you can achieve multi-room nicely (more flexible than the broadcast mode) and mpd does seem to handle synchronisation between multiple outputs. All you need is setup couple of pulse outputs with mpd and you don't need to bother tunnel module at all if your target pulseaudio's resample rate is fixed.

I have never used pi's analogue output and I always prefer usb sound card/speakers. If you have usb sound card powered by ti's PCM2702 or similar you will likely get a very clean sound.

ianmacs
Posts: 31
Joined: Mon Jul 09, 2012 10:42 am

Re: Multi-room audio solution

Mon Dec 17, 2012 9:11 pm

because of uneven latency introduced in your particular setup you will hear out of sync sound produced on different pi.
No. My experience with TCP was: For every restart of pulseaudio on one of the receiving pis, the synchrony between the receiving pis would be different. My particular setup, however, would not change. Also, the receiving pis were configured identically, so I have some problems in identifying the cause of the uneven latency.

Have you actually had the system running that you describe, with multiple receiving raspberry pis? And have you started it more than once? And had it running for longer than a day?

If so, I shall reproduce a setup as you suggest, with multiple mpd outputs on the sender, and see if I can reproduce your results. Would you be willing to help me debug my pulseaudio config if I cannot reproduce them?

Even if the receivers were synchronous initially, I would expect different receivers to drift apart due to inevitable clock drift, if said clock drift was not compensated for by adaptive resampling (see e.g. http://lac.linuxaudio.org/2012/papers/23.pdf) as is done by pulseaudio's rtp receiver.

eric.frederich
Posts: 11
Joined: Tue Oct 11, 2011 11:53 am

Re: Multi-room audio solution

Tue Dec 18, 2012 5:31 pm

Thanks for the replies.
Still haven't got my RPis yet.
Perhaps I will try doing a similar setup between my workstation and my laptop as practice.
I'd do this to get familiar with MPD and the respective clients.

My plan is to go completely wireless for the receivers.
Do you think I'll run into echo problems?
I thought that the PulseAudio network protocol was supposed to alleviate synchronicity problems.

I hadn't even though about multiple sources ("virtual playback zones" as you called them)
This sounds like a great idea. I'd probably start with 2.
Can you provide more details on your button configuration via GPIO pins and how you're interfacing them with the system?

Ideally I'd like an Android device to be able to broadcast anything it is currently playing whether it be youtube, spotify, pandora, etc.... but I'm guessing this is not possible without a ROM custom made for this purpose.
I was thinking Bluetooth might be an option via something like this...
http://www.newegg.com/Product/Product.a ... 6875982446
... which I already own, but the RPis don't have any audio input.
So the only way I can think of to get it to work on stock Android would be via Bluetooth, and then you get into range problems not to mention trying to find a Linux compatible a2dp Bluetooth receiver dongle.

MeMike
Posts: 11
Joined: Sat Dec 15, 2012 3:13 am

Re: Multi-room audio solution

Tue Dec 18, 2012 10:19 pm

Ok, have the set up working with wired connections.
Hi Steve, at least for me, multi-room audio is not so much a question of latency, but rather of synchrony. Pulseaudio's RTP receiver does this well. You may be correct about possible package loss when using wireless. Mike will have to test for this.
Spent the last little while trying this with wireless. The results are worse than icecast. I bought a Dlink DWA-131. Besides being a pain to configure for WPA2. Had to use wicd eventually. Now I have issues but this should work.

Will update as solutions are found.

Issues right now include what starts when. Chrony/wicd/pulse........ or HUB/USB NIC

PS the analog out on the Pi was not powerful to drive my active speakers. The USB Sound card works. Now have to wait for more USB Sound cards and some RPis.

Mike G.

eric.frederich
Posts: 11
Joined: Tue Oct 11, 2011 11:53 am

Re: Multi-room audio solution

Wed Dec 19, 2012 1:42 pm

MeMike wrote:Spent the last little while trying this with wireless. The results are worse than icecast. I bought a Dlink DWA-131. Besides being a pain to configure for WPA2. Had to use wicd eventually. Now I have issues but this should work.
I'm not entirely sure I understand what you're trying to say.
You're saying the results are worse than icecast but then that it should work.
Are you getting synchrony issues?

MeMike
Posts: 11
Joined: Sat Dec 15, 2012 3:13 am

Re: Multi-room audio solution

Wed Dec 19, 2012 2:22 pm

Eric,

Yes I am getting synchronization issues. Delay would be measured in seconds. Sputters and drop outs. The syslog reports look like when I had a flaky NIC driver. Doing some googling last night, I see that I'm not the only person with these issues.

I also lost access to the sshd server.

But the solution should work.

I'll keep reporting my findings as I get this to work.

Mike G.

ianmacs
Posts: 31
Joined: Mon Jul 09, 2012 10:42 am

Re: Multi-room audio solution

Wed Dec 19, 2012 8:59 pm

eric.frederich wrote:My plan is to go completely wireless for the receivers.
Do you think I'll run into echo problems?
I thought that the PulseAudio network protocol was supposed to alleviate synchronicity problems.
With wireless, you might run into dropout and echo problems. I believe it depends on the bandwidth and stability of the network connection. The pulseaudio RTP receiver, i believe, deliberately inserts half a second latency to allow for network delay, but if your packets are ever delayed more than this, due to network congestion, bad reception, cpu limitations, the individual receiver will play a pause and then increase the delay, at which point receivers get out of sync. That's what I got when stressing the systems. You have to ensure that the network bandwidth sufficient at all times and the cpus of the raspberrries have enough idle time.

I have not yet used wireless with a pi, and want to attach all of my pis to a wired network. My next bunch of pis will ship with one WIPI wifi dongle, I can try to attach one of the receiver pis wirelessly, then.
Can you provide more details on your button configuration via GPIO pins and how you're interfacing them with the system?
Not yet, only rough plans. As for the input device, I see two main options, GPIO pins as inputs, or a hacked usb keyboard, i.e. rip out the chip and connect its pins to my buttons. Then, a custom program which starts automatically on boot would detect pressed buttons and switch between zones.
So the only way I can think of to get it to work on stock Android would be via Bluetooth, and then you get into range problems not to mention trying to find a Linux compatible a2dp Bluetooth receiver dongle.
Interesting. I would have thought any bluetooth dongle would be able to function as a a2dp receiver if you configure linux accordingly, but then I know nothing about bluetooth.

ianmacs
Posts: 31
Joined: Mon Jul 09, 2012 10:42 am

Re: Multi-room audio solution

Wed Dec 19, 2012 9:12 pm

MeMike wrote: PS the analog out on the Pi was not powerful to drive my active speakers.
This is totally unexpected. What is the symptom? Your speakers are connected to a power supply, aren't they? Can you hear the analogue pi sound in a headphone? Perhaps it's the mixer volume setting? Start

Code: Select all

alsamixer -c 0
to set the volume of the alsa device, and alsamixer without parameters to set the pulseaudio volume (restart pulseaudio after doing this, as doing so introduces dropouts and increases the delay in my experience).

MeMike
Posts: 11
Joined: Sat Dec 15, 2012 3:13 am

Re: Multi-room audio solution

Thu Dec 20, 2012 1:51 am

ianmacs:
This is totally unexpected. What is the symptom? Your speakers are connected to a power supply, aren't they? Can you hear the analogue pi sound in a headphone? Perhaps it's the mixer volume setting? Start
Interesting results:

Rebuilt the RPi, clean build, Raspbian-2012-12-16, firmware 307, using dhcp on wire. (Work on the wireless with stable system next) The RPi audio analog output was slightly delayed (noticable) from reference system (Fedora 17-64) (AMD 4050e - dual core) .Volume was very low on speakers (Logitech LS11 - Cheap). top indicated less than 50% usage. Alsamixer was at 90. (Direct P/S, Hub attached).

Modified alsa-base.conf to depreciate snd_bcm2835. Used the USB card. Volume is up. and delay is gone. To me it seems that the USB Sound Card off loads the system. The system seems stable.

In another mater, my German is limited, is there another explanation of resample and the RPi

ianmacs
Posts: 31
Joined: Mon Jul 09, 2012 10:42 am

Re: Multi-room audio solution

Fri Dec 21, 2012 12:29 am

MeMike wrote: Used the USB card. Volume is up. and delay is gone.
Latency is also sound card specific. I hope to get better results by sticking to equal output systems.

My new pis have arrived, will test with 4 receivers as soon as everthing is set up.
is there another explanation of resample and the RPi
The need for adaptive resampling in situations like this is explained in the linuxaudio conference paper linked a few posts earlier. The fact that the default resampling method does not work on the pi when receiving RTP is just an observation.

gjerman
Posts: 3
Joined: Mon Dec 17, 2012 8:04 pm

Re: Multi-room audio solution

Fri Dec 21, 2012 6:25 pm

The PulseAudio RTP multicast over WiFi is totally unusable, even in case 802.11n network. It looks like WiFI getting over-saturated by UPD packets. Googling shows there is persistent WiFi flooding problem with pulseaudio's RTP since 2008, and it isn't resolved yet unfortunately...

MeMike
Posts: 11
Joined: Sat Dec 15, 2012 3:13 am

Re: Multi-room audio solution

Fri Dec 21, 2012 11:58 pm

ianmacs, thanx....

ianmacs
Posts: 31
Joined: Mon Jul 09, 2012 10:42 am

Re: Multi-room audio solution

Sat Dec 22, 2012 12:08 am

Today I experimented with 4 pis receiving the same RTP multicast stream, sent by a fifth pi.

With all devices connected using by ethernet, most of the time, there was no noticeable echo between receivers.

I sometimes noticed a small echo (up to ~1/3 sec) when restarting pulseaudio on one of the receivers. However, the time gap between receivers was closed about half a minute later, and then it stayed in perfect sync.

I also noticed that synchronized system clocks are not as important as I reported previously. Some time into the experiment, I noticed that one of the clocks ran late by more than half an hour. Still, playback synchronization was reached. How, I have no idea.

2nd experiment, connected one of the receivers using the wipi wifi dongle instead of ethernet cable. Playback started with several seconds difference. Again the gap was closed, but during that process, the pitch differed noticeable between devices, which sounded absolutely horrible. Once in sync, the wireless receiver would not stay in sync, but drift apart and resync constantly. I did not observe any drop-outs.

My conclusion is, I can use pulseaudio rtp for a multiroom audio, but only when using a wired network. I will not use wireless until this is fixed.

Working on my mutliple playback zones next.

ianmacs
Posts: 31
Joined: Mon Jul 09, 2012 10:42 am

Re: Multi-room audio solution

Sat Dec 22, 2012 10:40 pm

Three additions to my pulseaudio configuration hints given in an earlier post:

In file /etc/default/pulseaudio, additionally set the variable DISALLOW_MODULE_LOADING=0 on receiving devices.

Explicitly set the default resampling method also on sending devices.

On sending devices, add a parameter, so that one line in /etc/pulse/system.pa reads

Code: Select all

load-module module-native-protocol-unix  auth-anonymous=1
Otherwise, mpd can not connect to pulseaudio.

With the first change, I can report that it is possible in receiving devices to issue a command like

Code: Select all

pactl unload-module 14; pactl load-module module-rtp-recv sap_address=224.0.0.57
to switch the playback zone of the device executing it to the given multicast address. The number given to unload-module is the index of the currently loaded instance of the module-rt-recv, which can (among other options) be known from the response to the previous load-module command.

ianmacs
Posts: 31
Joined: Mon Jul 09, 2012 10:42 am

Re: Multi-room audio solution

Tue Dec 25, 2012 10:41 am

This is my script to switch between playback zones /usr/local/bin/set-rtp-source

Code: Select all

#!/bin/sh
LANG=C

# unload rtp-recv modules
while pactl list modules | grep -q "Name: module-rtp-recv"
do
	index=$(pactl list modules | grep -B 1 "Name: module-rtp-recv" | head -1 | cut -d "#" -f 2)
	pactl unload-module "$index"
done

if test -n "$1"
then
   pactl load-module module-rtp-recv sap_address="$1"
fi
It is called with the multicast ip address to listen to.

I have used a combination of two receivers and two senders for several hours now. While playback is often synchronized, it also often off by 1/4 sec or so.

I'm still undecided whether to accept this offset between different rooms or whether to hack pulseaudio to use ntp times when syncing receivers, as it apparently does not as of yet.

mrnegitoro
Posts: 1
Joined: Thu Jan 03, 2013 7:46 pm

Re: Multi-room audio solution

Thu Jan 03, 2013 7:58 pm

@s7mx1

I'd love to hear more about your set up.

i.e.) pulseaudio settings via /etc/pulse/system.pa and the script you mentioned

Cheers!

mrmichal
Posts: 1
Joined: Mon Jan 07, 2013 3:40 pm

Re: Multi-room audio solution

Thu Jan 10, 2013 12:28 pm

Did any of you achieved synchronization between more clients? I played with pulse audio configuration for a few days and music still has to be around 0.5s out of sync.
My setup:
Server without audio output with mpd, pulseaudio and ntp.
Raspberry pi with archlinux, ntp synchronization with server, pulse audio receiving rtp stream.
Laptop with ubuntu 12.04, ntp synchronization with server, pulse audio receiving rtp stream.

When I installed logitech media server to server and squeeze clients to raspberry and laptop music playback was perfectly synchronized.
Is there any way to achieve this with pulse audio?

Return to “Graphics, sound and multimedia”