URL Shorteners + Icecast/VLC

One additional thing I've been trying that seems to work well is using something like bit.ly.  We've been using it for linking to our online instructions, but last weekend I started using it as the URL for listening to the stream.  Now, instead of having to type in http://192.168.0.4:8000/live.mp3, the listeners can simply use bit.ly/CTEnglish.

So far, it seems to be working, though I haven't tried it on both iOS and Android.

Thoughts on Interpretation

I have a friend, Scott Garber, in the US who has been an interpreter for his church for a number of years.  When we started planning the new ministry, I reached out to him for some pointers.  With his permission, below are his thoughts:

1. It’s difficult to do the translation in the same space (or even off in a corner) as the main service. It just creates too much distracting noise. So, you have to figure out how the hearers are going to get the sound. At our church we give the listeners earpieces that fit over one ear and receive a radio signal (I suppose, as i don’t deal with the transmission of the sound). That allows them to follow the original audio as well. If you’re not going to translate everything (for instance, if you translate only the sermon) or if the listeners are also trying to learn Romanian, the live audio comes in handy. Plus, a full headset would make it hard to follow the live music.
2. The translator needs to be in a space where he or she can concentrate without distractions. I’m in a studio, where I have a monitor and a headset with a mic. It doesn’t have to be such a dedicated space, but stuff is going on around you that diverts your attention you’ll get behind and then have to start summarizing and paraphrasing to catch up. Or just lose track of what’s being said while you’re talking. You could do it without video, I suppose, but the video makes it a lot easier to follow. If the speaker writes anything or uses graphics, you’d get kind of lost without video. It also allows you to see the song lyrics if they are projected.
3. Translation works better if you have multiple services, even if you’re translating only one. That way the translator can attend a service before translating and think through/look up any tricky bits rather than being caught flat-footed. Plus, it allows the translator to have a worship experience, as translating is work. And to have any Scripture passages bookmarked before translating, so that those can just be read rather than having to translate them. If you have just one service there are things you can do to help the translator. All of these will also enhance the translation, even if the translator has a chance to experience the service beforehand. Having sermon notes ahead will allow them to make sure they have the best possible terminology for key words and main points. Plus, it will give them the Scripture passage ahead of time. If you want to translate the music, having the lyrics ahead of time is very helpful. If you’re translating into English, in many cases the translator could find the English lyrics. If not, it’s still helpful to see the Romanian lyrics, as poetic language can be trickier than normal speech, and it can throw translators for a loop. If you do dramas, it’s also really helpful to have that script ahead of time.
4. You have to determine which portions of the service you will translate. At the U.N. they switch out translators every 20 min. or so (I’ve been told). I do an hour and a half (minus some announcements and instrumental music), and it’s a lot. We don’t get the lyrics ahead of time, so not all of our translators even attempt to do music. Even though it would be handy to be able to switch out translators and keep them fresh, if you’re working with volunteers on a rotational basis it can get logistically hairy to find enough people if you have to use more than one per week, especially if that requires them to attend two services. 
5. I would suggest that you have at least a couple or three people that you can count on. One person might start with great enthusiasm but could easily get burnt out. Plus, if that person is away or ill, the people who have come to depend on translation are left high and dry.
6. If you are streaming the services you’ll have to decide whether or not translation will be part of that package and how to pull it off technically. You might want to work out the kinks and make sure that you’re really going to continue with translation long-term before you cross this bridge..
7. I think it’s important to have somebody who understands both languages monitor the translation, at least initially and from time to time, to make sure that you don’t have wildly divergent quality levels and that it’s actually working. Not everybody who is an expert in both languages can do simultaneous translation, so having some quality control can help determine if the translator(s) is capable. Feedback can also help improve performance over time. We don’t do this at our church, but I think we should. I know that some people, like me, are really translating, whereas I have the sense that some are just giving periodic summaries or very loose paraphrases. Your pastor(s) might not be happy to have people “flavoring” their messages too much.

Configuring Icecast and BUTT

In my last post, I described some of the recent changes we've made to our live interpretation tech and described some lessons learned.  Now I want to try and walk someone through the process of setting up a similar system to ours.  I'm going to focus on Windows, Icecast and Broadcast Using This Tool (BUTT).  I may add a second post to show how this can be configured using Linux as well, but for now Windows will do.

For starters, you'll need a Windows machine (probably Windows 7 based on my recent experience, though YMMV).  After that you will:

• Configure your Windows machine with either a static IP address or a DHCP reservation with your firewall.  (I'm a big fan of the DHCP reservation so you can take your machine elsewhere and it'll still work fine).
• Download the two packages mentioned above: Icecast and BUTT.

Install the Tools

• Install Icecast using the downloaded installer.  You can accept the defaults, but you might want to install it somewhere other than Program Files as you'll need to edit the configuration file and, given that it's a server, you might want to run as a non-system/non-privileged user.
• Install BUTT using the downloaded installer.

Configure Icecast

Icecast uses an XML configuration file.  Edit that file in your favorite text editor.  You will need to make the following changes (at minimum ... there may be more things you can do to harden the server).

1. Change the value of the <location>Earth</location> tag.  The value doesn't matter much, but Icecast will gripe at you if you don't.
2. Change the <admin>icemaster@localhost</admin> tag to your contact address
3. Change the <hostname>localhost</hostname> tag to your system's hostname
4. In the <limits> section:
1. set <queue-size>16384</queue-size>
2. set <burst-size>16384</burst-size>
5. In <authentication>, set the source, relay and admin passwords. 

Save the configuration and start the server with the icecast.bat file.  If you've done everything right, you should see a console window like this:

Configure BUTT

BUTT offers a nice UI for configuring the tool.  So, once you've started it, you can configure it using the UI.

Configure the server

1. Click the settings button to the right of the VU meter
2. Click the ADD button under the server drop down to configure your server.  Enter the following:
1. Name: I used localhost just because, but you can call it what you want
2. Type: Icecast
3. Address: localhost
4. Port: 8000
5. Password: <source password from icecast config file>
6. IceCast mountpoint: live.mp3 (or whatever you want it to be.  This is will be part of the URL for the Icecast server)

Configure Audio Settings

On the Audio tab you will configure the audio encoding settings.  The default assumes full CD quality 44100/stereo.  As this is voice only, you can greatly reduce your overhead and network usage by reducing this.  To do this, you will: 

1. Select your audio input device
2. Set channel to Mono
3. Set Samplerate to 22050Hz
4. Set the streaming bitrate to 64k

Save the settings and start streaming.

After you start, you might want to update the title of the stream using the Stream tab and update song name manually option.

Note: there is also an option on this tab to start streaming automatically.  Once you know you have the settings correct, enabling this option might be a good idea.  It simplifies the process.

Test

Now that you have your system up and running, you can test the sound by starting VLC (or any streaming client) and opening the stream.  You should adjust your audio to suit.

Documentation

I'm a big fan of creating documentation for volunteers to use.  As such, I created a HOWTO document for our team.  I've uploaded a sanitized version of this document here for you to use as a starting point.

Live Interpretation (Updated)

I had someone come to me today asking about the solution we are using for live interpretation.  Apparently news of this is starting to get around and this made me realize it's time to update the technical details and start posting some of my lessons learned.

Let's start with our current technology stack.  It's fairly similar to what we were using before, but we have managed to simplify it a bit.  Here's a list of tech:

• Hardware
• HP laptop (I don't have the specs currently)
• TP-Link TL-WDR4300
• Gatt MX-6 mixer
• Behringer UFO202 USB audio interface
• Sennheiser EM100 wireless microphone
• Software
• Windows 7
• Icecast
• Broadcast Using This Tool
• VLC for iOS and Android

The configuration is fairly straightforward:

• Connect mic to mixer
• Connect mixer to interface
• Connect the interface to the laptop
• Connect the laptop to router
• Connect router to internet
• Power everything on
• Start Icecast
• Start BUTT
• Start streaming

I will create blog posts to describe how to configure the software and a description of Windows vs Linux as a server OS for this purpose.  However, this is meant to be an overview of what we're using and how.

I also wanted to provide a list of issues we've run into so far and things to keep in mind:

• Internet connectivity is very important.  Our initial tests were on a local network with no internet connectivity and, while it worked, it did cause some issues.  Specifically, we started using TuneIn the streaming radio player and its initial setup required internet connectivity to move forward.  VLC doesn't, but you cannot assume the users will have enough data on their plan to download the software.  We now have a dedicated wireless network that does have internet connectivity
• Wireless channel selection.  Right now we are having some issues with cross-talk between the various routers in the house.  (sound tech, ours and others).  I'm hoping we can get around to assigning dedicated channels for these, but we're not there yet
• User friendliness: VLC, while a great app, isn't always the friendliest.  The iOS app will keep track of URLs you've listened to and that helps, but Android does not.  I'm hoping to eventually replace this with a dedicate app for CT, but that's a future enhancement.
• Audio Processing: Our current mixer has limited audio processing, specifically no compression.  BUTT doesn't offer any dynamics either, so we are looking at other options to allow us to compress and boost the audio a bit.  Also, don't skimp on the choice of microphone.  You could use an inexpensive computer mic, but I would think it would result in poor sounding audio and not be pleasant to the listener.  We're using a Sennheiser mic (which is probably overkill), but at least a Shure SM58.  Ideally you'd have a good plosive filter too.
• Dedicated space: one of the issues we have now is our interpreters are set up in the back of the theater.  This is for expediency sake at this point as they can see what's going on and hear the message.  There are two key downsides to this:
• The interpreters can occasionally be heard by the congregation.  To avoid this, they often have to speak more quietly than they would and that causes the volume to fluctuate for the listener.
• The listeners tend to hear the sound from the service flow into the feed we are sending.  This can be a bit distracting, especially given the lag.
• Latency: while the technology appears to work well, it does suffer from a bit of latency.  Each step of the chain adds a small time buffer to smooth out any network loss.  The configurations I use tend to reduce this, but it still adds up.  At best, we tend to see 3 second latency between when words are spoken to when they are delivered.  At worst, I've seen 10 seconds or more.  With VLC, you can simply stop and restart the stream to reduce that back down, but it's still something to keep in mind.
• Avoid Windows 10 (for now): I personally use Windows 10 and have since about the time it came out. (In fact, I'm writing this post on a Windows 10 Pro machine).  However, when I tried to use Icecast on Windows 10, something went wrong.  It worked in testing, but in production use, somehow the networking stack in Windows (be it the firewall or something) ended up killing all active connections.  It was so bad that I had to quickly restart into Linux just to continue the service.  We're currently using Windows 7 and it works just fine, so until I can figure out what happened, I'd avoid 10.
• GDPR: One thing Icecast will do is create log files.  Under GDPR you will need to make sure you handle those with care and follow your organization's privacy guidelines.  And if you don't have guidelines for compliance ... bring it up as it does matter.

At the end of the day, it's not the most perfect setup, but the price of starting up is fairly inexpensive.  Assuming you have a PC or laptop available, simply add the dedicated wireless router, mixer and microphone and you're up and running.

As we continue on, I will publish more thoughts and details.