Wednesday, January 19, 2022

First Publication

Wanted to let everyone know that I'm now a published academic author.  Last year, I presented a paper at the IEEE EDOC conference, or more specifically the VOTRE workshop.  Later last year, the paper was officially published and is now available through the IEEE.

The information in the paper will be the basis of my PhD thesis.  I'm now working on follow up papers that will attempt to add to and answer the questions from this paper.

Allen & Heath SQ vs Behringer Wing

For those of you who know me, you know that in addition to being a propeller head of the highest order, I am also a professional audio engineer.  It's not my day job, but something I tend to do on the side.  Given that, I've started haunting the r/livesound subreddit.  A few months ago, someone asked about the Wing vs other options.  I've been thinking about it for a while and decided that was a good time to put my thoughts on "paper".  As people found the answer useful, I thought I'd publish it here lightly edited.
 
Here's my take: those who love the Wing, really love it. I know some local engineers who have it and sing its praises. But I know others who don't. The split tends to be along the lines of X/M32 users love it and those who have used higher end consoles (DiGiCO, Yamaha, Studer, etc) don't like it as much.  Given that, as you're looking at a low/mid-level console, you need to ask the questions below.  And do note, this comparison focuses on the Allen & Heath SQ vs the Behringer Wing.
 
Like any question of this type: it depends on factors such as your budget, needs, and your choice of alternative.
 
Here's what I've started saying / recommending:
 
Are you an existing Behringer/Midas user (specifically into AES50)?
If so, then the Wing will likely be an upgrade, especially if you're hitting the top end of I/O in the X/M32 range. Below is my take on the pros/cons. Someone with more Wing experience might be able to add to the list.
  • Pros
    • More channels that can all be stereo (aside: is this a major upgrade as most vocal mics, instruments and other inputs are likely mono and won't benefit)
    • More effects (autotune clone anyone?)
    • Big touchscreen
    • It is newer so should be supported longer than a new X/M32 today
    • Fully remappable surface (you can make any fader on any layer be what you want it to be like the A&H SQ line and GLD before it as well as higher end consoles)
    • Generally more of everything
    • More flexible input/output mapping vs the X/M32 (yes firmware 4.x makes 1:1 patching possible but it's still more complicated than is necessary)
  • Cons
    • Bigger than a M32 Live / X32 Compact / X32 Producer (that might matter if you're having to move it constantly like a touring band where a smaller/rack mountable console might be better)
    • New patching system that is still different than the industry standard grid patching layout used by A&H, Yamaha, DiGiCo, etc.
    • (personal opinion here) Potentially a more cramped layout as they added DAW controls that are not necessary for live sound and (potentially) unnecessarily split the fade banks. The X/M32 (full) has 16 mix faders and 8 DCA/bus faders plus the mains fader. The Wing is 20 mix/DCA faders and 4 mains(ish faders). Yes, then can be remapped, but in my usage I found it to feel a bit cramped. Probably with time it might become more comfortable.
    • No real path upwards (Next step up is Midas Pro or Heritage series that may need new stage boxes to support 96kHz vs 48kHz for the Wing/X32 and the price difference is immense vs the path up in the A&H line)
    • You MUST have a stage rack as the Wing only has 8 inputs on the surface vs 16-32 on the X32/M32 mixers (the SQ series is similar)
    • No offline editor (as of Jan 2022) and iOS/Android apps still developing to meet feature parity.
Are you looking to start new with a Wing-level budget?
  • Consider the Wing of course as it's a fine console and will be broadly supported and see above for pros/cons vs X32/M32.
  • Consider the Allen & Heath SQ line as it has similar feature set:
    • Pros
      • 96kHz (there is discussion as to which is better, but it is a thing)
      • More options to upgrade (same stage racks work with the Avantis @ $10K and the dLive C/S-series $18k+)
      • Uses industry standard patching options (grid-based UI, same as DiGiCo, Yamaha, Avid, and A&H)
      • Three surface options giving same processing but flexibility for selecting the form factor / fader count needed (SQ5 16+Main, SQ6 24+Main, SQ7 32+Main)
      • Generally considered better sounding than the Behringer / Midas consoles, though of course opinions vary
      • True offline editor and feature complete iOS/Android apps
    • Cons
      • Stereo inputs consume multiple channels vs the Wing
      • Fewer FX and what they have are descendants of the 2004 iLive FX which are not always the best
      • Proprietary Slink port for audio connections vs AES50 which is a standards, though it has limited adoption outside the Behringer/Midas world.
      • More expensive components (surface, stage rack, add-in cards) than the Behringer side
For myself, I ended up skipping the Wing and SQ altogether and bought a Allen & Heath Avantis and love it. It has almost everything I could have wanted (short of a dLive, DiGiCo SD or Yamaha CL/QL) at a price that is probably better than anything else on the market at that range.

Friday, February 14, 2020

First Conference Session

Just a quick update, but I've had a conference presentation accepted for early March.  I submitted a proposal to the Workflow Workshop and Hackathon (WoWoHa) 2020 in Livermore, California and was accepted.

The conference looks to be great with a number of interesting presentations.  Maybe I'll see some of you there. 

Saturday, September 14, 2019

PhD v2.0

It was about two and a half years ago that I started publishing information about my presumed pending doctoral program.  Well, that ended up being sidelined because of the Romanian Ministry of Education.  In reviewing my application, they determined I was not eligible because I had not attended or completed a master's degree.

Whoops!

Nothing like selling everything you have and preparing to move to a new country only to discover that the primary reason (or excuse) you planned the move was not going to happen.  At least the educational system in Romania tends towards a "things get done at the last minute" method, so I was able to apply for a Master's Program at UBB instead.  And, while the process was annoying, it did end up with me having a better understanding of the process and a stronger line on what I will be attempting to research.

My original plan was to continue my loose work around text analytics, but the more time I spent learning the math involved, the more I started to understand that my passions lie elsewhere.  Now, that's not to say I won't end up picking this back up, but for now I plan on working towards a different topic.

Which brings us to the main thrust of this post: I have now been accepted into the PhD program at Universitatea Babes-Bolyai.  This time, I'm going to start looking into the intersection of workflow management and parallel programming.  Associate Professor Virginia Niculescu posed the following question during my last semester: what overlap is there between the workflow patterns (as documented by van der Aalst and Russell) and the defined parallel programming patterns.

With that thought in my head, I started my Master's thesis based on that, with a healthy dose of advanced case management thrown in.  Apparently, it was enough to complete my degree.  Now, I plan on working to complete the thought, as I believe there is plenty of room left to research the topic.  In fact, my thesis was about 80 pages (including project documentation) and I firmly believe that I could have easily added another 20-40 pages.

Follow this space (and my ResearchGate profile) as I move forward.  I'm already starting to write what I hope to be my first academic article and as it progresses I will try and update here.

Friday, July 05, 2019

Masters is (Basically) Complete

This may be slightly premature as I'm still waiting on the final grades from the University, but Wednesday 3 July, I delivered my thesis/dissertation defense and final presentation.  I believe it went well and hope to publish my final paper on ResearchGate as soon as the final grades are out.  In the meantime, here's the abstract:
Computers and information technology are commonly used to perform complex tasks more efficiently. Within information technology, two disciplines that are often used to assist businesses and other domains complete processes in a more efficient manner are workflow management and advanced case management. Workflow management is a discipline that is used to document, enforce, and streamline repetitive processes. Advanced Case Management is an emerging field that is an alternative to traditional workflow management and that offers more flexibility in completing processes. Both disciplines can provide additional efficiency gains through enabling business to distribute tasks to multiple users simultaneously.
Another discipline in computer science is parallel and high-performance computing. It offers users a similar ability to increase performance and throughput of complex processes through parallel task execution and work distribution across multiple systems. 
To explore the commonality between the three disciplines, this paper will review both the disciplines of workflow management and advanced case management from a parallel programming perspective. In addition, this paper will present a prototype of a new framework based on the guard-stage- milestone methodology of advanced case management, that has been built on the Akka actor model framework, uses a common big data NoSQL database for data storage, and can be used to demonstrate how an advanced case management system can be used to as a parallel task execution environment.

Saturday, March 09, 2019

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.

Friday, March 08, 2019

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.

Tuesday, March 05, 2019

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:
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.