Directsound buffer.. setvolume works.. sometimes

[svero]

With a directsound buffer I call setvolume to the last users settings. Problem is the window is not always in focus.. and if I do it when the window is out of foucus the volume setting doesn't take. If I do it when the game starts.. it doesnt take. If it do it in WM_ONACTIVATE it doesnt take. However once the game is up and running I can switch to my options dialog and drag the slider and it takes immediately.

Has anyone ever had this out of focus window problem before? Anyone know how to get it working?

[svero]

The problem is... essentially that when you say SetVolume(75) as the app starts up.. it caches the value but does nothing.(if the window is out of focus)... but then if you call SetVolume(75) again later when the window is back in focus it says.. oh im already 75 and just returns and does nothing.

[Bad Sector]

Hacked up solution:

Setup a timer to tick 300ms after the window's creation. Once it ticks:
Grab the active window (GetForegroundWindow() or something like that, without using the Win32 for some months i forgot most functions :-P), focus your game's window (SetForegroundWindow() or SetTopmostWindow() or RaiseWindow() or something in these lines i think), set a timer to tick in 50ms after this one and then when it ticks set the volume and activate the previously topmost window.

I suppose that this'll work...

(also i suppose that there is a more "polished" version, such as taking exclusive access to DirectSound primary buffer :-D)

[svero]

We're using that hack now actually, but it has the ugly side effect of the player being able to hear the sound adjusting when the app starts up (in this particular rare case) -- we want a non hacked solution.

[princec]

Surprised you're not using a more straightforward API like BASS or FMOD to take care of this for you...?

Cas :)

[svero]

Well we have a very nice api built on top of DirectSound. I'm not sure relying on bass or fmod would make these little very detailed particular bugs go away. I think in all likelyhood we'd just be forced to wait for bugfixes instead.

[James C. Smith]

I think we reapply the user's sound preference to the DirectSound object every single game update with no performance hit. In other words, we just keep resetting it many time per second for as long as the game is running. But the single line of code inside the loop rather than outside.

[Bad Sector]

How about using exclusive primary buffers as i said in my first reply's last line?

[svero]

I think we reapply the user's sound preference to the DirectSound object every single game update with no performance hit. In other words, we just keep resetting it many time per second for as long as the game is running. But the single line of code inside the loop rather than outside.

It seems to cache the value though and does nothing with it if you set it again. So the value gets set when the app is starting up but doesnt affect the volume and then later when we set it again after the user has taken back the window focus directsound just says.. well I'm already at that volume so... do nothing. So all the subsequent calls we make are ignored.

[svero]

How about using exclusive primary buffers as i said in my first reply's last line?

I guess im not sure what that is.. but it sounds like a big change to make for a small window focus bug...

[BitBoy]

It seems to cache the value though and does nothing with it if you set it again. So the value gets set when the app is starting up but doesnt affect the volume and then later when we set it again after the user has taken back the window focus directsound just says.. well I'm already at that volume so... do nothing. So all the subsequent calls we make are ignored.
If nothing happens when you set the volume to the same value, why not try to first set it to zero (or something else) and then to your desired volume? It might solve the cached-value-bug. Or it might not. Just a crazy idea that went through my head...

[Bad Sector]

IIRC, by having "normal access" to a DirectSound primary buffer, you have sound access to it only if your game's window is active. When unactive, you just can't do much. When having "exclusive access", you can do whatever you want, despite the state of your window and application. The side-effect is that usually no other applications can access the sound card (except if the drivers support it). But for a game this is not much of an issue anyway.

From what you said, i understood that you use "normal access".

Here is a related article in MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/DirectX/htm/cooperativelevels.asp)

By reading that article i saw that the exclusive mode is obsolete and replaced by the "priority" mode. This removes the drawback i said above. Heh, i just have a lot of time to write DirectX code. From the site:

Game applications should use the priority cooperative level in almost all circumstances. This level gives the most robust behavior while allowing the application control over sampling rate and bit depth. The priority cooperative level also allows audio from other applications, such as IP telephony, to be heard along with the audio from the game.

[gcarlton]

You may have to commit the changes with the DirectSound listener.