I hope nobody considers this too off-topic…
Here’s the situation: I’m working up some code to demonstrate the audio quality differences between software and hardware buffers, and I’m making a version that just uses DirectSound, and a version that uses FMod. What I did was I modified the Play3DSound sample from the DX SDK. Now, what’s happening is that I’m noticing that the audio quality is much better with FMod than the straight DirectSound implementation. This seems odd to me as FMod sits on top of DirectSound. In particular, what is happening is in the straight DirectSound implementation, the audio “glitches” when the sound gets positioned directly in front of or behind the listener (0,0,1) or (0,0,-1). So as the sound is sweeping from left to right, as it crosses the center line, it seems to have a discontinuity in the way the HRTF is applied (or something). That’s what I meant by “glitch”. It just kinda jumps from left to right abruptly. It seems to be much worse with a DS software buffer (DSBCAPS_LOCSOFTWARE | DSBCAPS_CTRL3D) than with a DS hardware buffer (DSBCAPS_LOCHARDWARE | DSBCAPS_CTRL3D). With FMod (both hardware and software buffers) the sound moves around the listener seamlessly. What gives? Does anyone who is familiar with that SDK sample know if the DirectSound implementation is buggy or inefficient at caching or anything? Thanks!
- audiocoder asked 13 years ago
Thanks, Brett! I appreciate the quick reply.
Anyone else able to offer any additional insight into this?
Much appreciated! BTW the soundcard is a SB Live! 24bit with current drivers in a very clean powerful machine (3.2GHz HT 1GB RAM etc.)
- audiocoder answered 13 years ago
I am also experiencing the same problem.
When the sound is to one side of the listener almost in front or behind them it will completely drop out on one ear as it gets closer to center. This seems to happen on just one ear with the rolloff seeming fine on the other one. It is a shame because it really kills the 3d experience.
This bug appears in both my app and the example 3D app that ships with fmod 3.74. The sound card is a sound blaster. I remember reading about hrtf issues with the sound blaster in another thread, I still get the bug if I turn off the HW3D and do it in software.
Is there a sound card that you could recommend that supports more than 32 3D hardware channels and doesn’t have this issue.
Thanks a lot
So the card I was using did not have 3D hardware support.
It looks like the problem occurs when fmod falls back to Directsound software 3D mixing. It may only happen with soundblaster cards.
I bought a Predator 5.1 by mad dog and the 3D HRTF sounds great!
I would recommend it as a good alternative to any Creative Labs card.
I am using headphones. The settings are correct for headphones. I am not accidently setting it to 5.1 or anything.
This is the issue.
With the cheap Sound Blaster I get the same problem as mentioned above and in http://220.127.116.11/forum/viewtopic.php … d+clicking
there are noticeable clicks when moving the listener fast over a sound source. The reason this is happening is from the fact that when you get VERY close to a sound either left or right of it (doing the 3D HRTF in software) one side will drop out. This drop out is a sudden change in audio levels which is most likely responsible for the clicks, when the listener is moved quickly.
I got the Preditor card and it sounded fine with hardware acceleration. There were none of the bugs I mentioned and the hrtf sounded good. But when not using the hardware and doing it in software the bugs were there and the same as with the Sound Blaster.
I then tried a Sound Blaster Live! 24 bit card which claimed 64 hardware channels but the bugs was there in both hardware 3D and software 3D.
The Preditor card was the only one so far that sounded good, but it only has 15 3D hardware channels. The fact that the bug appeared in the software mixing in that one as well as the Creative cards suggests that this problem is not exclusive to the Creative brand.
The fact that this bug is reproducable in the 3D example in 3.74 means that this is not an issue with my code either. You can hear one side drop out when you move the Listener slowly across the sound source in the example. It is easier to hear this with headphones.
Even though the one sided dropout is what you say should happen if a sound Source goes directly through the Listener, one of the cards I tried did not have that problem.
I guess some hardware people thought about what would happen if a sound past inside a listener’s head and others didn’t – thinking that the situation would never happen.
Offsetting the Listener from the sound Sources by a small amount did get rid of the dropout on the cards that had the problem.
Please login first to submit.