The Digital PA System (Part 2)

Our Public Address system is finally working! Well, basically. We still have to setup two sound servers for two rooms, but the system now works with one microphone as sound source, and 3 speakers as sinks to PulseAudio.

Our final setup will be as follows:

Building 1:

• 1.1. Computer with Speaker on 1st Floor
• 1.2. Computer with Speaker and Microphone on the 2nd floor
• 1.3. Computer with Speaker on 3rd Floor

Building 2 (150 feet away from Building 1)

• 2.1. Computer with Speaker on 1st Floor

Building 3 (30 feet away from Building 2)

• 3.1. Computer with Speaker on 1st Floor

We use 1.2 as our primary sound server, sending audio streams to 1.1, 1.3, 2.1, 3.1, and of course, to itself. To get the Mic working, we use the module-loopback to redirect Mic Source to Speaker Sink. Because dynamic automatic configuration of the module-combine does not work for remote tunnels, I installed a rather crude bash script/cron job to poll when sound servers become online and reconfigure module-combine.

!# /bin/bash
success=0

# Default Sink is the hardware sink
slaves=alsa_output.pci-0000_00_14.2.analog-stereo

# try to load each network sinks
pactl load-module module-tunnel-sink server=server1.local && success=1
pactl load-module module-tunnel-sink server=server2.local && success=1
pactl load-module module-tunnel-sink server=server3.local && success=1 

pactl list | grep server1.local && slaves=${slaves},tunnel-sink.server1.local
pactl list | grep server2.local && slaves=${slaves},tunnel-sink.server2.local
pactl list | grep server3.local && slaves=${slaves},tunnel-sink.server3.local

# Only revise combo sink if slaves was changed
if [ "$success" = "1" ]; then
  pactl unload-module $(cat tmp_module_combo)
  pactl load-module module-combine sink_name=combo slaves="$slaves" > tmp_module_combo
  pacmd set-default-sink combo
fi

The script is run every 2 minutes on 2.1's user's account.

 1.1, 1.3, 2.1, 3.1 are simply configured to accept network connections without authentication. We no longer use RTP sender/receiver as it is really killing all our wireless access points. Hopefully, this problem will be fixed in the future, as RTP multicasting really makes setting these sound systems easy.

The Digital PA System

We have a new project at our office, a Public Address (PA) system. A PA system seems a strange requirement for a small business like us. We already have redundant IM systems (A Jabber server as well as Empathy's distributed People Nearby service), but the argument for it is rather spiritual.

To implement the PA system, I voted to implement it the ultra-modern way, through the computer network. I've had my experiments with PulseAudio two years before, and from what I recalled, such a setup should be possible. We just have to weigh the pros and cons.

Pros:
1. Less capital expenditure. We already have a network. No need to put additional wiring to connect our disjoint offices which comprise three small offices, one of which a hundred feet away.
2. Flexible, programmable. Changes and expansions are as easy as connecting new speakers to a computer

3. It's a good experience

Cons:
1. Computers must be running on each area with the PA speaker. That's not much of a negative when there are already computers running in all areas
2. Network bandwidth. We have a combination of gigabit ethernet as well as wireless G.
3. It's pretty much experimental for us, without any professional consultants to rely on (or pay (which makes it a good thing...))

We're on the implementation stage now. We bought several two-way speakers and connected them to dual-core computers in each areas. These computers will act as sound servers. We had to use dual core computers after finding RTP multicast+gigabit network is a bit "demanding". (Most of our computers are Semprons or Atoms.)

Originally our plan was to use Pulseaudio's RTP multicasting for tremendously easy configuration. Unfortunately, we still haven't found a way to stop RTP from killing our wireless access points everywhere. We have some ideas to try like not putting any wireless access point/switch between any two sound server. Unfortunately, blocking multicasting on the wireless access points themselves are a no-go. We're just using inadequate consumer wireless routers that aren't configurable enough.

Today, I've gone to test fixed configuration instead using module-tunnel-sink and module-combine, with much success. I got my lowly laptop to act as master playing music to three other sound servers smoothly (and without stuttering when wired). I still have to solve the dynamic part, like reconfiguring the combined sink whenever a new sink comes up or one goes down. Maybe some bash scripts would help.

I'll update when I get this done and running.