02/06/24:: After 31 years of operating as an RSL station, as of the end of May's FM broadcast, Hastings Rock will be a full time Internet station. This was a decision made towards the back end of last year and was very much the stimulus behind the post I wrote in December with regard to setting up Playout to operate as an "automation hub" on a cloud server. However for obvious reasons I couldn't say that at the time because the announcement from the station had not been made. We now have two such cloud instances setup and going through the final stages of testing & should be switching over to use them later this week (at present the feed continues to come from a Raspberry Pi 4 hosted at my house)

In addition to all of this, for much of the first quarter of this year I have been developing a web based scheduling tool for them. This allows presenters to login and make requests to book broadcast slots. Once approved, those slots automatically appear on the schedule that is displayed on the main website. The tool fully manages conflicts and allows presenters to cancel or modify slots as needed. An additional feature the tool provides is to allow presenters to upload recordings of their programmes. These can either be new programmes or ones that have been previously broadcast which then allows the station to repeat them. Uploaded recordings are broadcast via Playout running on the cloud server. The scheduling tool has direct connectivity to the Playout database which (from the web front end) allows the adminstrators to load the audio into the system and setup a scheduled playlist for it to then run at the desired time. After a few weeks testing, the system is now live and fully functional.

27/04/24: I have been a little negligant this year in terms of updates to the site, particularly in terms of announcing the release of OAS Playout v4.2 (back in January!). Primarily, this is more of a "technology refresh" in terms of upgrading the tools that are used to build the software along with all of the supporting third party packages which are used by Playout. This version also marks the first 64-bit release available for Windows.

16/12/23: I was up visiting my longstanding friend James last month, amongst other things we discussed cloud computing (I was aware he'd been using Oracle's Always Free offerings to host a number of web services). I was interested to see how feasible it would be to stand up a version of Playout, accompanied by audio processor and streaming server, in effect operating as an "automation hub" very much like I do for Hastings Rock, Internet based broadcasts. As part of their offering, Oracle allow you to configure a number of different compute "shapes", one of of the most flexible being their Arm based Ampere A1 Compute VMs. Their offering (within the free tier) is quite impressive - up to 4 processors, 24GB RAM, 200GB storage, from a computational point of view far in excess of what I actually need. Once I'd signed up, it didn't then take that long to get something up and running - below is a screenshot of showing the setup, with Playout in a JACK configuration, routing audio through the processor, then out to an Icecast streaming server. This is all running in a dual core ARM configuration, with 3GB of memory.

24/06/23: Way back in 2010, I produced a set of Twitter modules for Playout, they provided the ability to post "track now playing" details to a station's timeline and (for the old 3.x releases), replies and responses in the scrolling message banner. Anyone who has any interaction with the social media platform is probably aware of the general level of chaos, disruption and mess that has come about since a certain Elon Musk took over. This included the removal of many of the APIs which third party clients used back in February however much to my surprise the modules continued to work (as did my noddy TwitStick client). That unfortunately didn't last, in April I received a "access to our APIs has been suspended" email but despite this, in the true chaotic style that Twitter has become, everything continued to work until early May.

Not only have Twitter changed their API, more importantly in order to continue to use it at the most basic level now requires a monthly subscription of $100/month. As such, the Twitter modules for Playout will unfortunately remain non-functional for the foreseeable future.

10/04/23: OAS Playout v4.13 has recently been released, aside from incorporating a number of bug fixes, this adds a minor enhancement to the sharing of remote database snapshots (see below), allowing for incremental updates to be uploaded. This can dramatically improve the export/import times and essentially completes the media sharing capability of Playout (although based on demand/interest I may add in support for additional cloud platforms).

In parallel, I've also started work on the v4.2x series, at present this is mostly a "technology refresh" which along with updating the tools used to build Playout (to Microsoft Visual Studio 2022), will also pull in the latest versions of the 3rd party libraries (eg. audio decoders etc.) which the system relies on. These will also be the first 64-bit releases for Windows.

This weekend also saw the first binary releases of Playout Express for Linux (for a number of Debian & Ubuntu releases). Whilst Linux versions have been around for a while (and been used a number of times to support Hastings Rock Internet only broadcasts, making binary release versions available to support not only the plethora of different distros that are our there but the differing versions that are supported at any one time was always going to be a challenge. Hence up to now, they have been built from source each time to suite a given distro. This is then my initial attempt to partially address that and hopefully will be able to continue to roll out releases to support this OS.

18/12/22: Back in October, Hastings Rock did an Internet only broadcast for a couple of weeks and this a good opportunity to roll out the media sharing capability which went into the 4.1 release. The generated playlist was then sliced up, based on each presenter's allocated hours and uploaded to a dedicated web server all within Playout Manager. The station's jingles and adverts were also uploaded in a similar vein. Express users were then able to download and import the audio into their system with a few mouse clicks. Well aware that not all of the presenters use Playout, I'd earlier developed a free standalone application OAS Playout Media Sync. This provides a similar front end to the cloud interface within Express, allowing packages to be easily downloaded and unpacked into a user specified folder. This allows interoperability with third party playout systems. An additional benefit of the system is that is allowed the easy addition of new audio as and when required. For example, some presenters ended up broadcasting additional programmes, it was therefore pretty straightforward to just upload an additional package of audio to them to cover those extra hours. Overall this new system was well received and performed flawlessly.

I've also just released OAS Playout v4.12, this includes the additional functionality I mentioned last time in order to allow "on-demand" content of audio from a central radio station. Essentially it allows remote presenters to download a snapshot of the database held at the radio station, minus the actual audio content. They can then add this to their existing database. When a track is loaded into Playout, it is automatically from the radio station, operating in much the same way as streaming audio services such as Spotify. There is one key difference, the content must be downloaded first before it can be played. This ensures that you won't end up with half complete or stuttery audio. Also not all of the file formats Playout supports can be streamed.

02/07/22: OAS Playout v4.1 has just been released, this enables the media sharing capability that I've been working on since September last year. This is essentially the first part of the project which provides the ability to share subsets of media content (eg. playlists) or provide a mechanism to "mirror" an entire Playout database which is useful if you have a remote or portable studio setup. In the next phase, I'm planning to add the ability to download audio content on demand.

This year also marked 20 years since Playout's first debut on Hastings Rock (and the first radio station it was ever used on) and I've written a short piece on this here.

08/01/22: Firstly, happy new year, let's hope the worst of Covid is now behind us and we can look forward to a better year. I've broken a little with tradition here in that rather than try and explain what I've been up to lately on the Playout front, I thought it would be easier to demonstrate it with a short YouTube video.

 

05/09/21: Back in 2019 (which feels like an eternity ago), I wrote on here about the idea of producing something which I called OAS Playout Web Manager, which as the name suggest was going to be a web based version of OAS Playout Manager. The Covid pandemic more or less put paid to that going anywhere in the immediate future however in the meantime the rationale behind that idea has evolved. One of the key challenges is that I'm not really a web developer and this would have involved a very steep learning curve. Additionally there are other challenges on the radio stations that would be using them, namely setting up and securing the web server this would be running on. And within the confines of a local area network, there are other, simpler means of accomplishing this with the existing software eg. using a remote desktop connection.

As a result, this has morphed into something called OAS Playout Express, which is essentially a new package with the same on air component but with a simpler back end management application. Aimed at more small scale Internet broadcasters, it's a significantly lower priced offering because it lacks some of the bells and whistles of Manager (such as voicetracking, scheduling etc.) that really aren't required if you're a part time broadcaster. Additionally, it's cross platform which satisfies the other aim of the Web Manager concept, namely of providing the ability to manage the Playout system within Linux. Some early versions were used to support the first of this year's Hastings Rock RSL (another purely online affair, using pretty much the same setup as I described last year) leading to the newly released OAS Playout v4.08 which is now available in an "Express" variant. Given the overlap with the Lite version, this has also now obsoleted that variant.

Whilst the Express application is, right now very much a cut down version of Manager, longer term I have further ideas which will greatly improve the manner in which presenters broadcasting from home for full time stations work. Conceptually this would allow them to combine their station's audio (and Playout database) with their own local copy, in a seamless manner.

10/10/20: We are now half way through a fortnight's Internet only broadcast for Hastings Rock (or "Rocktober" as they like to call it). A second broadcast of this nature is something that has been mooted for some time by the committee but has never really come to fruition. However the ongoing Covid situation and the success of the May Internet broadcast seems to have been enough to make it happen this year. Since this was on the cards after the aforesaid May broadcast, it's given me a bit more time to plan ahead, restructure a few things and address some of the issues from last time around.

Regular readers (are there any?) of this page may recall back in 2016 during the development phase of v4 that I had the Linux port up and running on a Raspberry Pi and I wanted to see if we could this instead of a standard PC, a primary reason being one of power (even more so if this were to become a regular thing). A Raspberry Pi4 consumes about 5W, compare to a desktop PC which is typically 100+ watts. We decided to drop the Teamviewer remote in option since that had very little use last time, instead all presenters would use the streaming in approach. Operationally, then it works in much the same was as before.

The key thing to address then was replacing the Voice Meeter audio routing solution, which proved unreliable for extended periods of time (plus it's only available for Windows platforms). Enter JACK which implements a software based infrastructure for audio applications to communicate with each other. Whilst also available for Windows, JACK is predominantly used in the Linux world. Whilst there are workarounds for applications that do not natively support JACK, one of the changes I made during the summer was to add JACK capability to Playout. This is now available in the newly released OAS Playout v4.06.

The other addition we added was the Stereo Tool software audio processor, which I was most impressed to discover had a JACK based Raspberry Pi variant. Predominantly this is used as a back end compressor to ensure all of the audio levels being streamed out are at the same level.

Originally I planned to run all this on a Raspberry Pi3 since Hastings Rock had already bought one of those in a previous year and I think from a processing perspective (the audio processor is the big driver here) would have been fine however we were very close to the 1GB memory limit and had seen a couple of out of memory crashes so felt it was safter to upgrade to the Pi4, in this instance the 4GB variant (complete with fan shim because there is a fair bit of load on this after all). Here it is running in all it's glory.

The Raspberry Pi itself is on the desk in the bottom left and so far it has all performed seamlessly.

30/05/20: OAS Playout v4.04 is now released, this wraps up a number of enhancements I'd been working on over the past six months plus the more recent additions to support the modes of operation used in the Covid19 remote deployment solutions I wrote about in the last two updates. One new feature I'm quite pleased with is the button wall behaviour when undocked in that is now snaps into a 4x3 grid of buttons rather than a single strip of 10 (as it is displayed when docked). This is much more user friendly in terms of then being able to reposition it on a second display plus brings back the two additional buttons we had to drop in v4 due to lack of screen space.

Hastings Rock have wrapped up this year's broadcast without any more hitches. The most disappointing thing was the behaviour of the Voice Meeter app with it repeatedly causing the audio to stutter/judder. This was a fairly repeatable occurrance cropping up every 3-4 days. Whilst we persevered with it for the 4 week RSL, this does effectively render it useless as something which can be used on a full time radio station. That said, it is something I plan on raising on the forum because it does seem a capable product and it would be good if we can get to the bottom of this.

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 last write up, 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 Icecast server 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 Future Developments page 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 good article comparing the two capabilities. Playout will use the EBU R128 standard 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.