Project Reality Forums

Hi all,
A question foa sound team;

I realize PR game sounds are directX, not directsound but... with the introduction of mumble running as a separate program which now adds to final mix, I'm curious if this changed anything?

To clarify, when two or more programs play sound under xp simultaneously or if volume slider in soundvol32 is changed at all from max in certain circumstances, this kicks in the kmixer and the Directsound resamples (obliterates) everything. similar story with win 7 hence the wasapi feature

Now normally BF2 engine sounds are 48khz and are rendered inside DirectX positional audio, bit-perfect provided the kmixer isn't active and coupled directly to the sound card 'pin', which may be SPDIF or DAC.

With mumble running, it's not clear how PR, directX and DS interact. It needs to be active at all time to relay voices of 'significant others'.

I have SPDIF on my beloved xfi hooked up to external 16bit successive approximation architecture dac sans digital filter. It would be a shame if direct sound was indeed re sampling anything.

WeeGeez wrote: Now normally BF2 engine sounds are 48khz and are rendered inside DirectX positional audio, bit-perfect provided the kmixer isn't active and coupled directly to the sound card 'pin', which may be SPDIF or DAC.

So what BF2 outputs is 48khz? Are you sure? The sound files themselves are 44.1khz.

More modern games are 48khz I'm aware.

fpspromotion wrote:https://www.realitymod.com/forum/f10-pr ... ality.html

That links suggests setting Windows default format to 96khz. This would upsample everything which is not good...

Jaymz I checked, bf2 audio is 48khz.
I concur that to re sample to 96, will bring no advantages as that link suggests.

Fyi, here is the information my concern is based on;

Contrary to popular belief, the kmixer of Windows 2000 and XP doesn't modify the sound and is thus bitperfect if these four conditions are met:

# The PCM/wave volume slider of the mixer (sndvol32.exe) must be set at its maximum.
# The player must be compiled for the same architecture that the OS was compiled for
# Applications other than the player mustn't play sounds, otherwise the two output streams will be potentially sample rate converted and mixed.
# Applications which are using the soundcard for recording have to use the same sample rate as concurrently running applications which are playing sounds - the soundcard has only one clock generator and hence this limitation arises.

Source
same applies in win 7.

So when mumble is active with sound, the directsound resampler becomes active, and that is bollocks considering the time spent field recording real world military gear.

I might make this a suggestion in the right forum, it's slipped in with the introduction with mumble and I think it would be worthwhile to look in to a way around the resampler - it really is optimised for efficiency which compromises the sound hence the emphasis on kernal streaming and more recently WASAPI in windows 7.

btw
I have other rather interesting suggestions / technical recommendations for the Squad sound team. I did ask on the forum but no reply there.

A case of who to ask.......

WeeGeez wrote:Jaymz I checked, bf2 audio is 48khz.

What is your source for this? The sound files themselves are 44.1khz.

Can you give an example?
I don't have it installed right now but when I checked BF2 files in an audio editor it said 48khz.

I don't think this difference matters, my point is, if two programs are running conjointly, even in windows 7, the lousy resampler kicks in. It's optimised for speed not quality.

Who's the sound dev on here?

WeeGeez wrote:Can you give an example?
I don't have it installed right now but when I checked BF2 files in an audio editor it said 48khz.

Look at any of the .wav or .ogg files in the PR folder. All 44.1khz , with some 22.05khz. I recall, from when I was a sound dev, that BF2 wouldn't play sounds that weren't one of those two sample rates. What BF2 actually outputs, I don't know for certain. But it would be odd if it were 48khz with 44.1khz source sounds.

WeeGeez wrote: I don't think this difference matters, my point is, if two programs are running conjointly, even in windows 7, the lousy resampler kicks in. It's optimised for speed not quality.

I'm curious, does it matter if the windows default format is the same as the games native sample rate? Would it resample something that's already 48khz...to 48khz? Or would it only resample the program that doesn't match?

If PR is 44.1 and mumble is 48 then windows 'corrects' that, usually to 48.
If mumble is 44.1 then I really don't know.
In any case sound card must supports final rate.

If the sound device is AC97, its restricted to 48khz, so resampler will be activated if data is not 48.
AC97 is old. Newer Intel 'HDAudiuo' and ATI/nvidia HDMI is more flexible.

Best way to test bit perfect is with spdif output to a reciever that either indicates sample rate or decodes DD/DTS data and use a encoded file.

I really have no idea if windows resamples if both streams are the same rate (in any windows), that is the fundamental question here, I might ask a more suitable elsewhere and report back.

Do you know what rate mumble is?

WeeGeez wrote:If PR is 44.1 and mumble is 48 then windows 'corrects' that, usually to 48.
If mumble is 44.1 then I really don't know.
In any case sound card must supports final rate.

If the sound device is AC97, its restricted to 48khz, so resampler will be activated if data is not 48.
AC97 is old. Newer Intel 'HDAudiuo' and ATI/nvidia HDMI is more flexible.

Best way to test bit perfect is with spdif output to a reciever that either indicates sample rate or decodes DD/DTS data and use a encoded file.

I really have no idea if windows resamples if both streams are the same rate (in any windows), that is the fundamental question here, I might ask a more suitable elsewhere and report back.

Do you know what rate mumble is?

Mumble is 48khz.

https://wiki.mumble.info/wiki/FAQ/English

An interesting quote,

The two most CPU intensive tasks Mumble performs are resampling and echo cancellation. The first of the two, resampling, is entirely avoidable on most audio hardware in existence today. Mumble operates on a native 48Khz sampling rate and if your audio device is configured to take/provide exactly that sample rate no resampling needs to be performed by Mumble.

In that case on Windows 7 in Speaker Properties, I'd set that to 16/44. 24bit is only useful you live in a anechoic chamber.

Unsure if PR sound will be re sampled if 44 is set.

XP? Unlikely to be a way around the directsound SRC that will definitely occur in this scenario unfortunately.

I mean even if mumble was 44, I've yet to discover how windows handles two concurrent streams if output supports 44.

I found some information on the Microsoft knowledge base here. This concerns XP mixer only. See attachment.

I had to read over it few times.

The highlight of that page is not in the attatchment. Theres a special command that BF2 can execute to "lock" the sample rate, in turn this would force condition four from the table, as mumble is higher than PR.

KMixer does not adjust its output rate when a client makes an IDirectSoundBuffer::SetFrequency call on a DirectSound buffer. Instead, KMixer adjusts the output rate when the buffer is first played.

Is this call accessible or hard coded in BF2?

WeeGeez wrote: In that case on Windows 7 in Speaker Properties, I'd set that to 16/44. 24bit is only useful you live in a anechoic chamber.

I set it to 24bit, since outputting 16bit content at 24bit is lossless anyway. But for the rare time I open a 24-bit file, I want it to play back without being converted/dithered to 16.

Agreed. Any comment on that call command?

I wouldn't know.