It’s been a while since my last post, and a lot has been happening…some of it slow, some of it bad, but most of it positive.
We took delivery of ten new computers a few weeks ago and are in the process of finding them homes. You’d be amazed how difficult it can be to give away something for free.
I talked briefly in my last post about WebRTC – the new browser-based real-time audio and video streaming technology from those clever guys at Google. It brings us a whole heap of benefits…
– No proprietary software or hardware required – just a compliant web browser.
– It’s platform agnostic – it runs on Windows or a Mac…or Linux.
– It’s open source. Although developed by Google, it is not a commercial venture as such.
– For TV, the broadcaster doesn’t have to use a ‘via Skype’ caption or logo.
– The built in Opus audio codec is excellent for our needs – on paper.
So, about that audio codec. It’s wideband, fast and efficient. The default implementation in WebRTC though has been driving me insane. Understandably, the brains who have developed – and to be fair are still developing – WebRTC are working on a Skype-like solution. It’s designed to work well with crappy microphones, noisy components, loudspeakers, and here’s the worst bit…members of the public!
Many of the features that have been built into WebRTC by default are designed to make the application work as efficiently as possible in the worst case scenario. For us however, with our posh microphones, closed back headphones and audio knowhow, it’s a bloody nightmare! Thankfully, a kindly chap at vLine has been patiently working through these issues for us.
Over the weekend, I was forced to put our development build of WebRTC into service when the IP audio software we normally use just wouldn’t hold a stable connection for the radio discussion we were facilitating. The main thing is, it worked. The connection stayed up for nearly two hours. The data compression was audible – due to a known bug / or feature – but the average listener would have been content.
The next night, we had another similar job booked for the same radio programme and despite previous successes, our usual IP audio software let us down again. No problem I thought, WebRTC to the rescue again. This is when one of those features I was telling you about – the ones that are great for the general public – came along and threw a digital spanner in the works. And it was all my fault.
There’s a feature in audio technology called AGC – Automatic Gain Control. If something’s quiet, it turns the volume up…if it’s loud, it turns it down. In some scenarios it’s useful, but it’s generally slow to react, and often far too aggressive when it does. Each time our contributor stopped talking, the AGC kicked in, and dragged the volume up. Then when he started talking again the signal distorted before rapidly decreasing in level.
Now, as with most of these helpful features, they can be disabled – but due to an oversight on my part, and the rush to implement the solution, I failed to do so. My heart sank when the programme abandoned our facility and did the rest of the discussion on the phone.
The good news is that the programme editor was sympathetic, we’ve established how to avoid it happening again, and one of Google’s genius developers has just come up with a probable solution for the issue of audible data compression. Thanks guys, the cheque’s in the post…to Dublin.
KEVIN
