NAG Online’s podcast has been a thing for the past six weeks and it’s getting easier with every episode to actually do it and get stuff up on to the website and the Youtube channel. But for the last few casts I’ve been noticing some very strange audio drift issues and I was quite sure that I was mucking it up somewhere in Audacity while cleaning out background noise. But no! This was actually a latent problem with Mumble itself.
The issue starts with Mumble’s audio recording function which was added for the client back in 2010 with version 1.2.3. For the next few years it wasn’t as popular as it currently is today for recording conversations and adding audio commentary into game streaming, There’s a large number of low-key podcasts, including ours, that uses Mumble for recording and it works pretty well. You don’t need to be running Skype and have several other programs running at the same time to record the audio and video streams, all of which have their own points of failure. Instead, Mumble does this natively and is completely unintrusive.
Mumble also has this really nifty feature that separates all the audio streams into multiple channels, all in mono sound. This is what I use to keep everyone’s streams apart so I can edit out Chris’ keyboard bongo drums or the occasional stutter I see from Mark’s internet connection.
But, you see, it only got added permanently in the stable channel for Mumble a lot later. A lot of people used it for recording but in the Mixdown mode. Over time, those who used Multichannel mode observed that whenever UDP packets didn’t get received from the Mumble server by the recorder that the recorder would wait roughly 100ms and then add in a buffer of between 0-3 seconds to avoid people talking over each other.
That buffer is just plain silence. Which, you know, doesn’t help when you want to keep the actual recording in sync. And it pretty much happens randomly as well. UDP, or the User Datagram Protocol, doesn’t have any guarantees that whatever you send out on the internet actually gets to the destination properly. It might get there on time or a little later and the inherent latency of UDP is the reason why Mumble’s recorder adds in a buffer when it expects audio to be there in the first place.
For now episode 6 of the podcast is in limbo, while I and others try to fix it properly. The bug makes audio drift backwards and forwards, so that means I pretty much have to listen to the podcast all the way through four times.
This behaviour was added into a bug tracker on Github and it’s been fixed now, apparently, but moving forward I’ll have to be more proactive in looking at other options. That may mean that our ability to do any of our shows live may be in jeopardy but this may not be a big loss considering that the most guests we’ve ever had listening in was a record… four.
So anyway, that’s just an update on what’s happening behind the scenes. Work continues to make the podcast better!