Feature request - alternative sample rates

[weegeez]

[skip to updated post]

Dear devs,

My favorite game is 44.1khz. This means windows SRC is enacted when streams from mumble, which is 48k join at kmixer level, as a result game sound is compromised.

Is it too much to add 44.1 support to mumble?

It's just that the sound team of the game in question spent considerable time field recording ambience and sounds and for the windows SRC to trash that is would be a shame.

According to Microsoft knowledge base article, if all outgoing rates are the same then no SRC takes place, the stream is simply mixed, not resampled.

Hope you understand, I'm passionate about the game.

Thanks in advance.

Edited September 26, 2017 by weegeez

[kissaki]

Are you saying using Mumble changes the systems audio output setting?

[weegeez]

Hi

The game is 44.1 and mumble (from what I've been told) works at 48k internally.

Because these do not match, the 44.1 stream will be re sampled to 48khz by default according to the windows direct sound sound layer (Kmixer). It usually rounds up butis dependent on sample rates supported by sound card, i.e. in rare case sound card only supports 44.1, mumble is re sampled instead, no problem here.

I'll add that in more recent windows OS, the output rate the hardware ultimately get can be forced but that has to be done manually.

Edited September 26, 2017 by weegeez

[weegeez]

Any idea?

[kissaki]

There is a constant SAMPLE_RATE in Audio.h, which is set to 48000.

This is used in several places to initialize sound input and output systems and codecs.

Maybe setting it to a different value would work, I don’t know.

[weegeez]

Interesting, I'd do some tests thanks!

[mkrautz]

There is nothing that really forces the WASAPI backend to use 48KHz. We could run it at something else, if there are compatibility issues.

For many other audio backends, we let the system choose. If it deems 44.1KHz a better fit, we will use that and resample to 48KHz on the fly for internal use.

[weegeez]

Hi,

Could not find Audio.h setting,,.

As I mentioned in post 1, in Vista/Win7 (UAA&WASAPI) it is possible to FORCE the output to a rate that the sound interface see's in the options, thankfully. However this is still not elegant enough, unwanted resampling may still occur because the average user;

A) Must manually do this so that it matches a games sample rate (see below).

B) Would need to know sample rate of the game to begin with, and

C) Keep a note of rates for all games and change these settings every time a different game is started.

http://lh4.ggpht.com/-ZRGkRPrVLig/TrBKcmm50AI/AAAAAAAAByY/NjQyNxsYttA/cmedia%252520modes_thumb%25255B1%25255D.png?imgmax=800

fig. 1 & 2, various ways user can FORCE sample rate in order to prevent resampling.

This problem is specific to mumble because it runs in the background and presents its own audio stream. i.e. Shared mode is inherent with mumble. If mumble (or any program with audio stream) wasn't open then resampling wouldn't occur, app is in exclusive mode in wasapi architecture.

Unless changed, mumble will continue to compromise sound quality of games.

Of course, none of this would be necessary is the audio/entertainment industry would settle on a sole rate once and for all but in the mean time these things need to be addressed.

In my case, I'm aware of this resampling, I only ever play one game and I know its sample rate, such is fortunate and I can put a tutorial in the games manual, instructing players to FORCE sample rates however this does not address other players and newer games.

It lays waste the efforts of those who perfected game sounds / effects.

It also makes both the equipment used to record sounds as well as sound devices used to play back those sounds, totally redundant.

So can someone please address this?

Edited October 17, 2017 by weegeez

[weegeez]

May I ask for more formal instructions on where to find audio.h setting and possibly how to change it?:

 

There is a constant SAMPLE_RATE in Audio.h, which is set to 48000.

This is used in several places to initialize sound input and output systems and codecs.

[kissaki]

If you have cloned Mumbles source code repository and are able to compile it, the file Audio.h is at src/mumble/Audio.h.

See on github src/mumble/Audio.h L#18

You can change it with a text editor.

Building Mumble yourself is/can be a bit more complicated.

See the "Building on " wiki pages you can find linked to at https://wiki.mumble.info/wiki/Development#Developer_How-To.27s

[weegeez]

Dear Kissaki,

Is that your real name? CooL

The developer of the clone in question can probably do it, if they haven't already. I'd need to find out who that is and ask them.

You say by changing this value, guarantee's various audio endpoints (and output) of mumble mandate one rate,right? Then no need to worry..

Are you familiar with software development specifically? I'd like to ask if its possible in windows applications to force output rate when in shared mode. I suspect it can only be done exclusive mode.

FWIW somebody else pressed a similar concern over at Passmark software forum. Evidently its an important issue that seems to be ignored alot of the time. Digital audio and multiple rates really is a bane in this age, alot of the time most equipment is not used to their full potential, for both recording and playback and that fuzzy software part in between aswell, regrettably.