Naxxfish

Recently, CSR FM have aquired a Soundweb London BLU-100 (which I’ve raved about in the previous post). Amongst the myriad of things which it can do, it can also do some quite complex signal processing. Currently, the CSR FM airchain goes from program output (via a switcher), to a DSPXmini FM processor – which processes the audio and compresses it so that it’s of uniform loudness, then on to a 50W FM transmitter (of which we’re only using 25W).

Unfortunately, the FM processor does not have an audio output on it, only a MPX signal which goes directly to the transmitter (which has fancy things like stereo pilot and RDS encoded into it directly) – as such in order to do our online stream we have to have a FM tuner tuned into the frequency, which then gets distributed to a few places, including a Delta 44 on the encoder machine which then goes out to the online stream.

This isn’t ideal, for a couple of reasons.  Firstly, any FM signal gets a bit distorted no matter how close you are to the transmitter (it’s directly below it in the rack, in fact).  Secondly, the FM signal adds ‘clipping’, which is essentially cutting the peaks off waveforms flat.  You’d normally say this is distortion – and it is!  However, over FM, being an analogue medium, this actually sounds good and can add to the loudness of the station if done right.

But when going over a digital medium, it sounds horrible (and sounds like the input on the soundcard has been saturated).  It’s especially bad when you encode it into a lossy codec such as MP3 – the square edges of the waveforms have lots of high frequency components (check out this video demonstrating how using the Fourier series a square wave is made up of an infinite number of sine waves of increasing freuquency).  An MP3 encoder tries to compress the audio by removing ‘useless’ information, that is frequencies that the human ear is less sensitive to.  If you throw in lots of high frequency components, it ends up thinking that these are important frequencies when in fact there is much more valuble information that it can compress in different parts of the spectrum.

So, we can come to the conclusion that using a clipped audio source for lossy digital transmission is not good.  This applies to online streaming as well as other digital media like DAB, DVB or XM broadcasting.

Therefore, we need a separate audio processor which does everything that our FM processor does, except without the clipping.  If we had a better processor – such as an Orban Optimod – it would have two outputs, one with clipping and one without.  Unfortunately we don’t have that much money to spend on processing, especially with the Studio 2 project ongoing.  So, therefore I decided that we might try to build our own processor using the BLU-100.

In essence, a broadcast processor has a few general stages which it uses to make the audio output of the station sound uniform and punchy.  Namely, these are -

• Wideband processing (gating, AGC, compression)
• Multiband AGC
• ‘Enhancement’
• Multiband limiting/compression
• Final limiting/brickwall limiting

A bit like this:

My mission is to implement this using London Architect.  I have pretty much all the components I need in the audio processing section of my BLU-100, so lets give it a shot!

Continue reading “A Walk through a Broadcast Audio Processor”

So, I decided that CSR Technical Services needed a blog. So now it does! Here’s a copy of my first post there, about the recent issues we’ve had with the Station Switcher

Here at CSR, we have a number of different places which we might want to broadcast from.  For example, we have two studios (Studio 1 at the University of Kent, Studio 2 at Christ Church University) a sustainer service and we often perform Outside Broadcasts which require taking a signal from another source again.

Therefore, we have an airchain which includes a station switcher (specifically two Sonifex Redbox OA3 daisychained together to give us 5 possible audio sources).  In order to allow presenters to switch the station output between the sustainer service and the studio output, we provide two buttons – offer and accept.  The station switcher allows the operator of a studio to “offer” to take control from other studios, and “accept” control for other studios.  The sustainer, since there is no human present, cannot offer to take control – therefore a special case is given whereby the studios may force it to take control by holding the offer button then pressing accept.

The buttons (and indicator lights) are connected to the station switcher via a D-sub connector, which goes into a control interface. This is fine – however we wanted to be able to control the switcher from within Engineering where the switcher is located.  Thus, many years ago, one of the Tech crew built a 2U rackmount box which allowed us to “press” the offer and accept buttons remotely.  It essentially consisted of a box with a bunch of push to make buttons mounted on the front panel.

However, there was one slight issue – Studio 2 is at a remote site, and obviously we can’t run a piece of wire from the buttons half way across Canterbury to the switcher!  Therefore, we made use of the remote GPIO pins on the MDO STL-IP units which we use to transport audio to and from Studio 2.  This allows us to send digital signals (i.e. high or low) over IP – we connected up a switch box at Studio 2, plumbed this into the GPIO ports which were replicated up at Kent.  However, the signals which came from the STL-IP unit were not the same as the ones required by the switcher.  Therefore, in our custom made box we had to build some level shifting circuitry which converted the levels to ones which the switcher could accept.

This circuit was built on veroboard, and looked a lot like this:

The chip at the bottom is a octal darlington array, the one at the top a hex inverter. This successfully shifts the level, and everything worked perfectly for the time which we had Studio 2 online.

This all worked just fine up until recently – however when we took out the STL-IP boxes for maintainance we discovered a slight flaw.  Since the STL-IP box was disconnected, the inputs on the CMOS inverter were floating.  This caused the control signals to the switcher to fluctuate wildly – this in turn caused the switcher to constantly give Studio 2 control of the switcher!  This was not good (thankfully we have backups in place to prevent this being a showstopping problem).

The solution: attack the insides of the switch box with a hacksaw, remove the circuit, and disconnect it permenantly.  Now, it shall never bother us again.

Until we need to work out how to remotely put Studio 2 on air.