Not sure how many users this will affect, but here are the details:
- we upgraded our development machines from 4.04.28 to 4.08.01
- we then noticed a problem with 3D HW sounds that was not previously present in our application
- specifically, until the listener actually moves, no new 3D HW sounds are audible, and no error is returned from play()
- the bug can be re-produced using only the stock FMOD examples, no user code needs to be involved
- in 4.04.28, run 3d.exe, press the spacebar to pause the listener, and toggle the sounds on and off with 1 and 2
this works on every machine tried, the sounds pause and unpause and are audible and inaudible as expected, with the listener stationary
in 4.08.01, do the same thing, but when you turn off the sounds and then turn them back on they are inaudible until the listener is actually moved
this happens only on some machines (two notebooks with latest audio drivers, but not on any desktops we tried)
it seems like something has changed since 4.04.28 where the listener properties are cached and FMOD doesn’t pass them along unless they actually change, causing no subsequently played 3D HW sounds to be audible, this was confirmed by slightly jittering the listener every frame (even when it is not supposed to be moving), which resolves this problem on all machines tried in our application, but isn’t really a good long-term solution…
- also, 3D SW sounds are not affected by this, 3D HW ones only…
VisualStudio2005 + Win32 (WinXP)
- srprog1 asked 10 years ago
Symbiotic, the machines are not all the same.
as1psx, the laptops both have Realtek HD audio, and software 3D sounds work normally in both FMOD versions on them, just 3D hardware ones have been afftected (and only on RealTek, due to some listener change since 4.04.28 )
Brett, the last paragraph in my post is the important one – we’re not talking about the sound buffers being at fault, we’re talking about a stationary listener being at fault – on the RealTek devices with 4.08.0X it seems you have to actually change the listener every frame (even minutely!) just to get FMOD to actually commit the new listener props to DirectSound or no further 3D HW sounds are audible. Reverting back to 4.04.28 (the next most recent release we had kicking around) solves this problem, even with FMOD’s own examples AND NO OTHER CHANGES. Anyway, as as1psx says, the solution is to check for Realtek in our app and just force all 3D sounds to play in software, something new that we didn’t need to do with 4.04.28 on such hardware.
You seem to have completely missed or ignored what I said.
FMOD doesn’t do position delta checks on the sound. It passes vectors straight to directsound. setPaused isn’t even interested in 3d position. All it does is call IDirectSoundBuffer::stop and IDirectSoundBuffer::start and there is no 3d code involved.
Now because you’re talking about such an old version I can barely remember how it worked (it would be in our perforce logs but i’m not at the office right now) , but they key change is probably something to do with switching to the commitdeferredsettings method which is for -performance- reasons. We didnt ‘introduce a bug’. We switched directsound functions to wring some more performance out of the already slow directsound api.
If fmod was doing position delta checking, [b:bpp5b99x]ALL[/b:bpp5b99x] soundcards would have this bug. I’m not trying to avoid the issue (which as I mentioned is probably not our issue) we will most likely have to work around it somehow, but ‘it worked before’ is in no way useful to us. You have to give more information about the hardware and if it is confined to one type of soundcard so we can actually do something about it.
Its possible we might have to ‘jiggle’ the directsound buffer 3d position before unpausing it. Can you verify that something like this fixes the issue?
This is again the reason I recommend people use FMOD_SOFTWARE. There is no point using hardware mixing these days, and you don’t even know what other soundcard driver bugs are out there in the wild.
I looked back at my original post, and I am not sure how to word it any clearer. The problem is [b:12rprv72]NOT[/b:12rprv72] with IDirectSoundBuffer::Stop or IDirectSoundBuffer::Start. Jittering the [b:12rprv72]LISTENER[/b:12rprv72] fixes the problem (ironic, eh?) - I suggested that you might have been caching [b:12rprv72]IDirectSound3DListener[/b:12rprv72]'s position (or as you're indictating, using CommitDeferredSettings with [b:12rprv72]IT[/b:12rprv72] recently for performance).
Here are reproduction steps:
1.) Get or borrow a notebook with Realtek HD integrated on-board audio and insure the latest drivers are installed (although it will likely happen with any of them – we even tried the ones that shipped with the laptop).
2.) Create a small FMOD test app on Win32, setting it up like you yourself recommend for Windows. I referenced your 3D.exe example, because without any changes to it you can reproduce the problem.
3.) Play a 3D sound that is FMOD_HARDWARE (3D.exe plays two such sounds, looping)
4.) Update the listener, and then do an FMOD system update (as normal – the sample does this)
5.) Any sounds played [b:12rprv72]before[/b:12rprv72] that very first listener/system update play just fine on all machines.
6.) Now try to play the same or any other 3D HW sound afterwards (even pausing/resuming one of those first looping ones from the sample that WERE audible) at any time afterwards and you won’t hear them on the Realtek HD systems (and who knows what other crappy integrated audio solutions as well?)
7.) Then [b:12rprv72]MOVE[/b:12rprv72] the listener (even by 0.01 in any single axis) and suddenly all 3D HW sounds are audible again, but if you don’t update the listener, or just update it with the same position, the sounds on the Realtek systems remain inaudible for good – [i:12rprv72]including ANY subsequently played 3D HW sound until such a listener change occurs[/i:12rprv72].
I was providing as much information as possible by telling you the last confirmed FMOD version that it worked in, so you could just fire up Perforce or whatever and diff your code that wraps IDirectSound3DListener between those two versions to narrow in on a solution or work-around.
If it is a Realtek driver or HW bug (which is 100% likely, I agree) related to using CommitDeferredSettings with [b:12rprv72]IDirectSound3DListener[/b:12rprv72], it could potentially affect thousands of end-users of the latest FMOD without having a higher-level work-around in place right now. Whether that work-around is from Realtek (unlikely, plus it wouldn't help those users who don't keep their drivers up to date), from Microsoft in DirectSound (unlikely, for the same reason, plus they'd just rightfully blame the IHV, and we won't be seeing more DX9 updates soon anyway), or in FMOD, or at the application level, I was just letting you know about the bug, since doing a work-around in FMOD helps the most developers and end-users shipping PC titles in the short-term ([i:12rprv72]+5XP for that run-on sentence[/i:12rprv72]). Perhaps keeping silent and just fixing it in our app and then reading the hundreds of online forum posts in the future from stimied Realtek users of games and apps integrating the latest FMOD would have been more entertaining than this pointless argument?
fmod doesnt do anything with the buffer’s 3d position when it is paused.
It also simply calls stop/play on a directsound buffer, and there is no caching involved by fmod. It’s possible the bug is in the actual soundcard driver itself, and the difference is that we’re using different function calls to give performance with hardware (ie DirectSound::Commitdeferredsettings etc.)
What is common about those 2 sound devices you mentioned. If it works on most machines and not a few, fmod’s code can’t really be the cause unless there is something we have to workaround due to a faulty driver.
The behaviour you describe doesn’t reproduce on any of our machines, as i said, that pause code simply calls a directsound buffer stop and start which is quite common.
Are all of the machines the same? If, as a1psx says, Realtek chips are an issue, and all your dev machines use the same chipset, it isn’t far-fetched to think that a code change could exploit something weird across all machines (if they’re the same). If some of the machines are different, I might then look to FMOD as the cause…
- Symbiotic answered 10 years ago
Please login first to submit.