As I’ve told in an older thread, I had some crashes with fmodEx, but I was not yet sure where they were located.
After some more tests, it appears that they are Access Violations which occur in/around FMOD::Sound->release
My program structure is:
create fmod system object,
[code:2rki5zap]fmod_result = fmod_system->createSound(fileName, (FMOD_MODE)(FMOD_SOFTWARE | FMOD_2D | FMOD_CREATESTREAM | FMOD_OPENONLY | FMOD_VBRACCURATE),NULL , &fmod_sound);[/code:2rki5zap]
get data using fmod_sound->readData(&tmpBuffer, 2048, &read);
and sometimes seekData
when the user closes the stream, sound->release is called, and this crashes sometimes.
Now I think (but I’m not absolutely sure) that the problem is related to readData calls just before closing. Maybe the actual decoding is done in another thread, which could possibly still be working while sound->release is being called?
My application is multi-threaded, but I made sure that it is not possible that readData, seekData or sound->release are being called simultaneously, and it is also not possible that seek/read is being called while release is being executed.
- Adion asked 13 years ago
My problem was not with specific mp3’s that crashed all the time, and the fmod functions were written in Visual C, not Visual Basic.
But I think the problem was probably on my side, and had to do with concurrency issues.
I tried to add EnterCriticalSection/LeaveCriticalSection calls around the fmod calls, and the problem seems to have dissapeared.
So probably the first thread sometimes called readdata at the same moment that sound->release was being called.
Thanks for the information and clarification.
Based on the various accounts, I’m fairly confident that the underlying problem is the same. That is, the mechanism producing your problem is very likely the same mechanism producing the problems in VB.
Ok, in VC there may be a workaround. In VB, there is none (that I can see).
I don’t think the problem would be the same in Visual Basic, since Visual Basic itself is always single threaded, so as long as open->read->close are always in this order there should be no concurrency issues in visual basic. (unless read is being called from a callback in another thread for example)
[quote="Adion":1w4eucga]I don’t think the problem would be the same in Visual Basic, since Visual Basic itself is always single threaded, so as long as open->read->close are always in this order there should be no concurrency issues in visual basic. (unless read is being called from a callback in another thread for example)[/quote:1w4eucga]additionally, unless FMOD Ex is significantly different in how it uses threads from FMOD, I can’t think of a reason it would have just ‘stopped working’ because of threads.
- Janus answered 13 years ago
Please login first to submit.