Hi! If you read my last post you’d know that I’ve been experimenting with ways people can seamlessly broadcast without the need of a permanent studio – perhaps if you have presenters at home that can’t get in; your studio(s) are shut due to the pandemic, or maybe you’re just looking for a cool solution for outside broadcasting on the road? 🚗

I’m designing this system with small/student radio stations in mind, there are problems with it; but from tests, it’s been a very useable platform to work with. I’m also going to refer to Discord as a VoIP (Voice-over-IP) client, even though I’m designing concepts with Discord just to test.

The concept was the ability to run a fully-featured playout system in a web browser, and use a service like Discord (which also happens to run in a web browser) for two way high-quality audio. Sounds simple, right? However, it has several problems I’ve tried to tackle to start, such as:

  • 👮🏻‍♂️Security – Remote sessions are (especially lately) becoming very widely used, so many software developers of said software’s and protocols are and have been working hard on improving all-around security in common applications, but you still don’t want to be throwing out direct IP addresses and login credentials on the open internet. An RDP Gateway server should at the minimum be running to at least put a bit of shade on the real identity of the remote PC for security. Windows Server has this sorted, but if you can’t/don’t run Windows server; a nice freebie called ‘Guacamole’ by the Apache team can be run on as small as a Raspberry Pi (and via a Docker environment on something like Docker!) to help keep you protected. You can even manage and assign RemoteApp and desktop access to a custom user database via this tool, which is very handy for web login access. Other steps like Windows Group Policy tweaking I’d also highly recommend to block as much of the rest of the OS in question that isn’t needed out. I’m not going to list everything I’ve done for security here out of interest to keep my own systems secure; but here are some tips:
    • Strong, multi-factor authentication on RDP gateway accounts
    • Disabling all local network resources and access on the remote machine
    • Frequent password changes
    • perhaps even a network proxy?
  • 🎧Internal audio routing, processing and encoding.
  • 🔥Latency and poor network connections.
  • 🎙A multitude of ‘non-broadcast’ quality microphones, and inconsistent audio levels.

The main pieces of software I’m using for this ‘demo/proof of concept’ are Google Remote Desktop Services, RadioDJ (stop judging because of the name, it’s a good peice of software!) and VB-Audio’s Voicemeeter and Virtual Audio Cables.

Here are the instructions presented to the broadcasters when they log in via the website:

web-Login Screenshot

The ‘Remote Playout Machine’ is headless. Discord is running, hidden in a system tray and permanently connected to the aforementioned ‘BROADCAST’ Channel.

Here’s our virtual mixer,

Voicemeeter Banana Mixer

Banana is the donationware version of this particular software; although I believe everything we need could be done on the free version. (but don’t quote me on that.)

On my current working proof-of-concept version; this mixer isn’t touched and all the audio levels are automatic – however, maybe with touchscreens you could implement this software to allow users to mix more thoroughly their output.

RadioDJ Settings

Here I’ve sent the MAIN Broadcast output of the playout software (you could do this with other software, of course) to the AUX Input, which comes up on that fader I’ve named ‘Playout.’  Hardware out A1 is a virtual audio cable to the input of discord (server-side) so that you can monitor what you’re doing on the discord client-side. This playout system has a built-in encoder which features a compressor, multiband-EQ, stereo enhancer and AGC (Automatic gain control), however as an alternative or to get more control over your output, you could route another virtual audio cable from A2 to another broadcast encoder of your choice. OR, use a real interface output to a physical encoder or different machine input. With this method, you can make use of Voicemeeters built-in patch channel ‘VAIO’ to add your own third-party virtual or physical compressors, broadcast processors etc. Here’s one I tried out called ‘MBProcess’:

MBProcess

You can also see the VoiceMeeter options where I’ve patched in MBProcess at the bottom under channel 1 PATCH INSERT. Because the output of the audio chain ends up in this VAIO Fader (I’ve named it Broadcast Return), we can send that to A2 where our encoder would live. (The encoder being the master output to your radio station streaming server/antenna.) We could then use the A1 button on this VAIO fader to act as a kind of ‘Broadcast Listen’ to quickly send the processed output to your VoIP service like Discord for monitoring. A virtual cable between the server-side VoIP output and VoiceMeeter’s channel one input can be made to effectively get a fader for the ‘Host/Presenter Mic’, nice! Technically, you could go even further and experiment with voice effects, EQ and compression right within VoiceMeeter at that point, but I chose a simpler method for now.

Whoa whoa whoa, hold up a minute.

A virtual mixer on a regular laptop is hard to control, possible but can be tricky. So let’s get rid of it and make the computer do all the work. (as an audio engineer, I hate that sentence, btw.)