OAS Playout News/Development
Current State of play...
OAS Playout V4.0 is now released - retail/licensed versions & free demo copies are available. You can read about the current product & features here.
The free demo version is available for download here.
Pricing, purchasing & licensing options are here.
Already OAS Playout has been deployed successfully on a number of RSLs and community stations over 2002-18 with very positive feedback on all fronts. Watch this space for news on latest updates & progress.
17/05/20: The Covid19 outbreak also impacted Hastings Rock's plans for this year's usual May broadcast, with the usual FM broadcast being postponed. Instead we're mid way through an Internet only broadcast with the presenters broadcasting from their own homes. This is the first time we (and the station) have attempted this.
The technical starting point for this builds upon the solution I outlined in my , with one key difference in that there is no need for an external mixer (or a complete studio setup for that manner). Instead the output of the Voice Meeter mixer app is fed via another virtual audio cable instance directly to the audio streaming encoders that then send it to an external and hence the world at large.
Many of the Hastings Rock presenters have their own studio setup or have the necessary gear to put one together fairly easily. Therefore in addition to providing the remote-in/Teamviewer capability, we offered the ability for them to use their own setup instead. This required a few tweaks to the system. The "studio" (hosted here) is running a pre-release Playout v4.04 which I enhanced to extend the remote control interface to allow starting & stopping of automation via an external application.
When a presenter is due to start broadcasting, they send a private Internet stream to a locally hosted Icecast server. The routing of this out to the wider world and the control of Playout and the software mixer are all controlled via a dedicated Python script.
The starting scenario is to run up Playout in automation mode. The Python script sits in the background polling the status from the local Icecast server. When it detects the presence of an incoming stream (ie. a presenter has just connected), it issues the remote commands to take Playout out of automation and stops playback of audio. It then un-mutes the mixer channel that would normally be routed to Teamviewer. Sat running on the PC is an instance of VLC Media Player. VLC also has a simple remote control interface that operates over HTTP. Therefore the Python script utilises this to request it begin playback of the remote presenter's stream (from the local Icecast server), the audio output of which is routed into the software mixer on the same channel as Teamviewer would use thereby sending it out to the Internet.
When the presenter finishes their show, they just disconnect their stream. When the Python script detects that the stream is no longer available on the local server, it mutes the mic channel again and puts Playout back into automation - which will then provide the audio output for the station.
The schedule for the broadcast puts an hour period of automation between each live show, this avoids any contention on connecting up to the private stream at the start/end of each show. During most of those periods, listeners can request tracks via the website and these get automatically inserted into the playlist. This is something we've done overnight (and continue to do so) for many years with great success.
So far things have gone well. Most presenters are using their own studio setup for this and the switchover between them and the Playout system has more or less been flawless. We've had a slight audio "juddering" effect which seems to be caused by the software mixer and seems to kick in every 3-4 days which is odd. Restarting the audio engine seems to fix it. The only significant thing is that we could really do with some form of audio compressor/limiter on the back end. The levels from the different presenters and local output from Playout is somewhat noticeable and probably something we should have thought about. However given this is the first time we've done this I think we can be forgiven for this.
09/05/20: Right now everything is of course about Covid19. The UK is still in lockdown with no real idea when it will end or what the world will look like when it does. The small scale community stations (some of which use Playout) are but one of many thousands of outfits that are and will continue to be impacted by this tragedy. To play my small part in trying to help with this, you may have seen on the main page that I'm waiving license fees for any existing or new customers wanting to use my software for the foreseeable future. There is more information on the purchase page.
In the weeks before lockdown, I'd been really busy here because it was fairly obvious where things were heading and it was soon going to become difficult if not impossible to have presenters on site in radio studios. A fallback option is of course pure automation but keeping these stations going was (in my opinion) an important part of keeping up people's morale whilst we are in this situation. The basic starting premise here was simple, given most presenters at community stations won't have a suitable studio setup at home: be able to remote into and use the Playout system with the minimum of additional equipment. In essence that boils down to: a PC, a microphone and headphones.
For the remote desktop software I used Teamviewer, it's a package I'd used before and works quite well plus is pretty straightforward to install and use. It also has the ability to route audio to/from the remote end which again simplifies things.
A key challenge is that Playout was designed to be (and still is) first and foremost meant to be a "live assist" package and as such isn't really geared up to be a standalone broadcasting solution. It's outputs are normally fed into an external mixer along with any other audio sources (including the presenters mic input). This clearly doesn't work in this configuration, instead some sort of software mixer is needed on the PC to replace this capability. For that I came across the rather nifty Voice Meeter application. This provides the ability to mix in 3 distinct audio sources (2 physical, 1 virtual, potentially more depending on the underlying audio architecture), onto 3 outputs (2 physical, 1 virtual) with various routing, filtering and muting capabilities.
Architecturally this is the solution I came up with:
The audio from Playout is actually fed into the mixer app via two virtual audio cables - another invention by the author of the Voice Meeter app. One end of the cable appears as a sound output device and the other a sound input device hence by attaching a "playing" device to one end and a "recording" device to the other you can easily route audio between disparate software applications. I'd been using one for some time now to route the audio from podcasts to a local Icecast streaming server for beaming around the house.
Both these and the Voice Meeter app are "donationware" so before anyone asks yes I have donated to both!
One of the other useful features of the Voice Meeter app is that is has a remote control interface which became pretty vital as the actual application window itself isn't resizeable, not a problem if you have two monitors but that is likely to be the exception rather than the norm. Plus Teamviewer doesn't deal with multiple monitors in a particularly useful fashion. So evolved the vmeter-playout "widget".
This consists of two dialogs which "float" over the top of Playout (it's actually a completely separate app). The first of these (on the left) gives the presenter control over his/her mic input level, it also offers a simple means of muting and Pfl'ing the mic channel. This controls the appropriate faders on the Voice Meeter app via it's remote control interface. The second of these (on the right) gives the output levels plus the ability to pal the two Playout channels. Those additional volume controls (which serve as faders for the two Playout channels) are actually part of Playout itself however they are normally hidden (on older versions they sit either side of the clock). There are also two keyboard shortcuts "Z" and "X" which automatically drop (and restore) the volume levels by preset (configurable) amounts.
As we trialed this it became obvious that for the most part having fine grained control over the faders wasn't necessary for many of the presenters. Just using those keyboard shortcuts sufficed for the most part especially since we were mixing in the digital realm it was impossible to max out and hence distort the output levels from Playout. Once the mic levels had been set, there was no need to change them. The Link checkbox on the mic dialog took this one step further, if enabled it coupled the Mute toggling to the volume controls within Playout. This meant everytime the mic was unmuted, the volume levels from Playout would be automatically dropped (and likewise restored when the mic was muted). However as with a lot of the capability within the Playout system, the flexibility is there for the presenters to use it in whatever way is most comfortable for them.
The vmeter-playout widget works with all the current v3.8x and 4.0x releases of Playout and is freely available on request - just drop me an email. I also have a fairly comprehensive user guide on how to set all this up.
Using Teamviewer for the audio routing quickly threw up a bit of a problem in that it requires the remote end to confirm routing of their audio to the connecting party. If you're connecting to an unattended studio that's going to be a bit of a problem hence the Tv button on the widget. When pressed, it simulates a mouse click on the Teamviewer panel which activates the audio link. Realistically it is a complete hack and doesn't work if the dialog has been moved or say the taskbar hidden but for the purposes of getting something up and running quickly (which was the key thing) it suffices.
The other issue with using Teamviewer to route the audio is the quality is pretty poor and furthermore is quite CPU intensive, I was seeing a significant jump to 50-60% on a dual core processor. Whilst trialing this with the guys at Unity 101 they pointed me in the direction of a package called Mumble. It's basically chat application package that came out of the gaming community but has since found uses in other arenas. Setting up the server wasn't overly straightforward, the documentation isn't that great but once it was up and running the audio quality (and latency) is much better with the advantage of much lower CPU overhead. It does however involve the presenters needing to install additional software which complicates things.
Hastings Rock are one week into their (Internet only) broadcast for this year. The Covid outbreak has also meant they've had to operate differently as well and I plan to do a write up on how that's all working over the next few days. In the meantime, stay safe and look after yourselves (and neighbours).
30/12/19: OAS Playout v4.03 was released early last month, as mentioned in my last write up the significant enhancement here was the addition of the loudness normalization capability. I have also just released OAS Playout v3.89 which is the last planned version of the 3.x series - this is just a minor bug fix release.
I've also just updated the to summarize the next thing I'm going to be looking at, namely something I'm (currently) calling OAS Playout Web Manager. As the name suggests, this would be a version of OAS Playout Manager in a web browser. There are numerous benefits to this - within the confines of a radio station's local network, it would allow anyone to make changes without the need to have an instance of Playout, including tablets, phones etc. If the system is made accesible to the outside world, it then extends this to allow presenters to prepare programmes from their own homes. The initial focus will be to allow the update of existing database content - primarily focusing on playlists, rather than allowing the addition of new audio content since that has significant security concerns and other major issues that need to be overcome. At present I'm just exploring the concepts for this, to that end and with Windows 7 reaching end of life early next year I've been upgrading and setting up various dedicated build enviroments to support this new activity. I've also put together a dedicated VM to support maintenance updates (should they be required) of the now legacy Playout v3.x releases which are still actively used by stations.
08/09/19: I released OAS Playout v4.02 in the middle of last month, this following on from the successful Hastings Rock broadcast in May (using v4.01) and a pre-release version used on another local RSL, Carnival FM. This release has again been very much focused on Playout Manager, fixing a number of long standing minor bugs and enhancements that I'd been holding off on till now. Much of this therefore isn't immediately obvious, arguably the most significant thing being that it is now possible to update the database information with metadata held with the audio file that has been updated since the file was originally imported. Prior to this update, the only way of accomplishing this capability would be to delete the file from the database, then re-import it again.
Work on the next update is now underway, which will incorporate a new feature referred to as Replay Gain (or Loudness normalization). This adds to the Audio normalizing capability which Playout has supported since it's initial incarnation and has predominantly come about to compensate for the high level of compression applied to modern pop music whereby this is perceived as much louder as (for example) music released in the 1980s (and earlier). This process works by analysing the audio content (performed by Playout Manager) to determine the average loudness of the track against an industry recognized level. During playback, this is then used to reduce or increase the volume of the track such that all tracks "sound" the same. This process is subtly different from audio normalization where the affects are much less noticeable by the human ear. Wikipedia has a comparing the two capabilities. Playout will use the for it's implementation of Replay Gain. This update will also allow normalisation process to be performed automatically as part of the import process (rather than requiring it to be done as a seperate post processing step).
22/04/19: As I mentioned at the back end of last year, the primary development focus now has been on finishing the overhaul of Playout Manager, with the result being a revised v4.01 release coming out at the end of last month which incorporates the new version. Whilst mostly a behind the scenes piece of work to bring everything into the same development enviroment, this version has improved support for "high DPI" type displays (such as modern laptops or 4K type displays) with the result that visually the icons & bitmaps look less blocky or pixelated. I've also given the website a minor overhaul to update many of images and information to bring it in line with the latest software.