Mumble bandwidth question

[mjpatey]

Hi, all-

I had a brainstorm and installed Mumble today, hoping to use it to do real-time voiceover between my home studio and other studios. There are several professional products that do this, but it looks like Mumble could be tweaked to do it, too, and at zero cost!

So what I need is the highest bandwidth connection possible. I'm running a test server on Windows 7. I've edited my murmur.ini file to require the Opus codec, and allow a maximum of 256 kb/s (I believe I can set it as high as 512, which is Opus' maximum, but I don't think my Internet connection would handle it so well).

The problem is, my Mumble client maxes out at 96 kb/s (which, with the overhead from my current latency settings, adds up to around 124.8 kb/s). I'd like to set the audio bit rate to something higher than 96. At least 128, if not 192. The Murmur server supports this, apparently, but the Mumble client app only allows it to go up to 96. I can't imagine the developers of Mumble would allow the server to go up to the limits of the codec, but not give the client a way to use it. Is there a hidden config file for Mumble that will allow greater audio bandwidth than 96kb/s?

Thanks in advance for any light you can shed!

-Mark

[kissaki]

No, there is no hidden config file for the client. I believe you would have to tamper with the clients source code and compile it.

Are you aware though that for similar quality levels Opus requires way less bitrate/bandwidth than MP3 for example? So maybe the 96 would be enough after all?

[mjpatey]

Thanks for the reply! I have heard of Opus' superiority, and that's what led me to this package. :-D The problem is that my voice using Mumble at 96Kbps sounds pretty awful on the tests I've done so far. Don't get me wrong, I'd be thrilled with it in any other context, such as telephony, but it doesn't hold up against purpose-built voiceover transmission apps I've tested so far.

Here's how I tested... maybe you can see something I did wrong. I used Mumble's built-in recording function while connected to a server on my LAN. The reported codec bitrate was 96Kbps, but on playback, I was getting all sorts of underwater-like sounds from it, especially during quieter portions. A lot like a Skype conversation. Basically, it sounded like there was a lot of audio bitrate reduction going on, like the artifacts you get from realtime noise reduction. Not codec bitrate reduction, but the bitrate of the original uncompressed audio before it hits the codec (as if it were dipping down from 16 bit 44.1K to 12-bit, to 8-bit, etc. on quieter syllables. I've heard this before when someone encodes to mp3 at way too low a level. When you try to bring the level back up, it sounds all watery because you're trying to expand only a few bits' worth of audio back up to the full 16 or 24 bit range (kind of like pixellation in the audio realm). That's what this sounds like when the level dips even a little in Mumble. I have noise reduction and echo cancellation turned off, and am using the "always-on" option, so it's none of those things. I also tried adjusting the packet size, but it had no effect. I'm trying to feed it a healthy audio level, and I believe I am, but it's hard to tell using Mumble's interface.

I did just read that although the Murmur server can be set to accept any connection bitrate, it's apparently only meaningful up to around 130 kbps. Which would mean that even if I were able to adjust the Mumble client to allow Opus encoding at 128 kbps, with the packet overhead it would be too much for Murmur to accept and it would likely get bumped down to 96 again anyway.

Anyway, thanks for listening. :-) If anything in my jumbled mess above rings a bell or gives a clue as to why I'm experiencing less-than-optimal audio, please do tell! Thank you.

-Mark

[Dodge]

Here's how I tested... maybe you can see something I did wrong. I used Mumble's built-in recording function while connected to a server on my LAN. The reported codec bitrate was 96Kbps, but on playback, I was getting all sorts of underwater-like sounds from it, especially during quieter portions. A lot like a Skype conversation. Basically, it sounded like there was a lot of audio bitrate reduction going on, like the artifacts you get from realtime noise reduction. Not codec bitrate reduction, but the bitrate of the original uncompressed audio before it hits the codec (as if it were dipping down from 16 bit 44.1K to 12-bit, to 8-bit, etc. on quieter syllables. I've heard this before when someone encodes to mp3 at way too low a level. When you try to bring the level back up, it sounds all watery because you're trying to expand only a few bits' worth of audio back up to the full 16 or 24 bit range (kind of like pixellation in the audio realm). That's what this sounds like when the level dips even a little in Mumble. I have noise reduction and echo cancellation turned off, and am using the "always-on" option, so it's none of those things. I also tried adjusting the packet size, but it had no effect. I'm trying to feed it a healthy audio level, and I believe I am, but it's hard to tell using Mumble's interface.

 

I'm having the same issue, and I'm surprised I haven't heard of, or found a solution to it yet. It definitely sounds like Noise Suppression is still on, even when set to "off". Does anyone have a solution to this? Even if the solution is editing the source code and recompiling?

[hacst]

Just a side-note. If you are recording make sure to use the snapshot clients. 1.2.X has some major issues in that area that have been fixed since then. As to the audio quality: 96kbit/s mono Opus should be plenty of bandwidth to get a high quality transmission (production quality? Wouldn't know since I'm not involved in professional audio). Not sure about the processing. If there's part still on that would explain the quality issues but at the moment at least I don't have the time to look into that. The pre-processing definitely has a lot of areas that could use some love.

[Dodge]

Just a side-note. If you are recording make sure to use the snapshot clients. 1.2.X has some major issues in that area that have been fixed since then. As to the audio quality: 96kbit/s mono Opus should be plenty of bandwidth to get a high quality transmission (production quality? Wouldn't know since I'm not involved in professional audio). Not sure about the processing. If there's part still on that would explain the quality issues but at the moment at least I don't have the time to look into that. The pre-processing definitely has a lot of areas that could use some love.

 

Thanks for the quick response! You put me on the right track to figuring out my issue. Going off the Opus wiki:

http://wiki.hydrogenaud.io/index.php?title=Opus#CELT_layer_latency_versus_quality.2Fbitrate_trade-off

32k is "Essentially transparent speech". My tests seemed to confirm this, when having a conversation I couldn't tell a difference between 96k and 32k. So I moved forward with 32k. Sometime later I realized the audio sounded like noise reduction was still on, even when set to off. I confirmed this by recording only noise, turning the volume all the way up, and comparing it to a quicktime recording made at the same time. The Mumble 32k recording had significantly less noise than the Quicktime recording.

After reading your response, I tried with 96k, and it sounds almost identical to the quicktime recording! It seems I was confusing bitrate compression artifacts, with noise reduction artifacts.

User error! :oops: