I’m getting a crash when I call setPosition on a channel. I’m also getting a weird problem where the stream will just stop playing.
This is a reproducible case, and seems to be something with threads (as it seems to be a speed issue at the moment).
I get the crash/weird in my application, but by adding a small chunk of code, can get it to also happen in playstream.
To reproduce, do the following:
Open the Playstream example, and swap to the Debug CPP build configuration.
Now goto line 90 and insert the following case statement:
[code:2x09kg2q] case ‘a’ :
unsigned int ms;
result = channel->getPosition(&ms, FMOD_TIMEUNIT_MS);
channel->setPosition(ms + 1, FMOD_TIMEUNIT_MS);
(Right after the case statement for the space bar handler)
Now start the application…It will begin to play the 11:54 long song. While it is playing, start mashing the a button.
This is the fastest way i could find to reproduce the issue, but it has happened to me even without quickly setting the position, but the callstack suggests that it is the same crash I get normally anyway.
So doing this method, you will get one of two things (that I have experienced). One, is that it will stop the song playing, (while it is no where near the end of the song), and two, it will crash. The crash callstack looks as follows:
To reproduce the crash, the best thing is to quickly press and depress the a button. To reproduce the stoppage, the easiest is to hold down the a button. Sometimes it is a combination of both, one after the other. (don’t you love reproducing threading issues?? :))
I’m testing this on a p4 2.8ghz intel machine. It was also doing it on a p4 3ghz machine (but i wasn’t able to test if it was just doing it for that machine or on others until now)
I also get a similar crash using setPosition.
More accurately, I can debug it and see that it is crashing in my SOUND_PCMREADCALLBACK callback.
It seems that the unsigned int datalen that is being passed to the callback is extremely large, thus causing an exception because I try to read over the edge of the data buffer.
- Adion answered 12 years ago
I’ve heard that the white noise can be caused by DirectSound. In debug mode it fills the audio buffers with noise to give you an indication that you’ve not initialized the buffers correctly. Not sure if that’s it in this case, but it’s something to look at.
- Adiss answered 12 years ago
I’m also getting another bug when I play WMA files.
When I setPosition on them, you can hear the stream completely restart, but the song keeps playing from where it was (i.e. it appears to ignore the setPosition (getPosition still returns, and increments as usual), but the audio you hear is from the start of the stream).
Can be reproduced easily using the playstream example, using the same modification as above (with the ‘a’ key). And instead of the .wav file, playing a .wma instead. Press the key and see what you hear. If it doesn’t do it, press again. You will know you have it, when you hear the song restart, but the time is still ticking up.
Good call on the DSound whitenoise. Changing to WINMM output got rid of that, but I’ve still got clicks/pops on streams. I’d like to change back to DSOUND, though, so I hope you can find the issue.
Streams also don’t seem to play to the end and FMOD_Channel_GetPosition() seems to be messed up as well (returning the wrong time).
I sometimes get the last part of a stream repeated followed by FMOD_Channel_GetPosition returning an error (FMOD_ERR_CHANNEL_STOLEN usually and FMOD_ERR_INVALID_HANDLE once). This was with only 7 channels in use (I have virtual channel max set to 256).
[quote="VOR":1qomhsga]Good call on the DSound whitenoise. Changing to WINMM output got rid of that, but I’ve still got clicks/pops on streams. I’d like to change back to DSOUND, though, so I hope you can find the issue.[/quote:1qomhsga]Brett’s the expert here, but in my experience, the issue is most likely that ‘creative labs writes shitty drivers’.
- Janus answered 12 years ago
[quote="VOR":1670jws0]True, but it didn’t used to do it, so I’m going to have to point to FMOD Ex at the moment as the cause (I can go back to older beta or FMOD classic and it goes away).[/quote:1670jws0]
If it’s the DSound debug causing problems, and you want to use DSound, trying going into your DXDiag util, and activating Release Mode drivers, not Debug Mode, and the sound problem should be fixed.
(Of course brett should possibly run in Debug mode drivers to verify this still, but at least it could fix your problem ;))
I don’t even have an option to set the debug output level for DSOUND (they removed it in the summer update of the SDK). Anyway, two of the machines have never had the SDK installed, just 9.0c runtime so that isn’t it. I’m also not running debug D3D, just retail. No system settings have been changed between the working and nonworking releases.
Since it only happens on streams, the file streamer does sound likely. I seem to be able to make it worse by increasing the decode buffer size. I also tried increasing the file buffer size but it didn’t seem to do anything.
I’ve been playing with playstream a bit more. I replaced the wave.mp3 it plays with a speech ogg that contains “That’s where you can buy food and other supplies”. When it starts, it plays “ss where you can buy food and other” then stutters, plays to “other”, then starts playing “that’s… ” through to “other” and loops. I can send you the file if it helps.
Please login first to submit.