in earlier versions I always got a crash when releasing a sound which was still loading when created with FMOD_NONBLOCKING flag. With the newest version 4.14 this doesn’t result in a crash any more. In this way I could abort a sound from loading. I’ve been looking for such a function for a long time. I experimented with a loading thread, but using fmod functions from different threads is discouraged. The only problem with the new solution is that sound->release() then stalls the application for a few seconds. Is this bahaviour intended or are there easier ways to abort a sound from loading?
Thanks in advance
- mylo asked 10 years ago
How about you use the loading callback’s, and just pass that info through normally, but if you stop loading for whatever, get your callback to generate an error, like an EOF or something early?
Not sure if it would work, but it’s maybe something worth testing?
- a1psx answered 10 years ago
if it is playing and you call release, it will stall while it shuts down the sound and file reads.
If you poll getOpenState it will tell you in a non blocking way if the stream is ready to release or not. FMOD_OPENSTATE_STREAMING means it is still active. When that flag dissapears you can release the sound without it stalling.
Thanks for your answers a1psx and brett!
Your suggestion seems to work. In the file read callback I return end of file early, so the function returns (almost) immediately. But I’m running into another problem…
Is FMOD_NONBLOCKING for streams only? Opening a sound with FMOD_CREATESAMPLE flag set always stalls my application. There seems to be no hint in the docs that non blocking is for streams only. Or am I missing something? I call system->createSound exactly like in the non blocking example in the docs.
Sorry brett, it does indeed not block. The problem was the thread priority of the non blocking thread, because it is so high, my app stalled for 1-2 seconds and I thought that was the create sound call. If I set my app to highest priority it runs fine.
This might be a dumb question… but how did you change the thread priority of your main application?
Is it better to change this, or change the thread priority of the ASYNC thread? Why does the ASYNC thread have a higher priority than the default OS thread (the app)?
- collision answered 10 years ago
According to the docs FMOD uses THREAD_PRIORITY_ABOVE_NORMAL for the async loader thread on Windows. There seems to be no way to change this. I would prefer a priority something "below normal" and leave the priority of my app "normal". Setting the thread priority of your main app differs from platform to platform and the framework you are using. I’m using qt4 and it is very easy to change the thread priority of the app.
Can you confirm that this works? For me the variable for percentage of load in Sound::getOpenState is always 0, the openstate variable seems to be correct and changes from 1 to 0 when the sound is ready. I’m using the latest stable release of FMOD.
chk(system->createSound("C:/Temp/test.mp3", FMOD_NONBLOCKING, 0, &sound));
chk(sound->getOpenState(&openstate, &percentbuffered, 0));
cout << "openstate: " << openstate << endl;
cout << "percentbuffered: " << percentbuffered << endl;
} while (openstate != FMOD_OPENSTATE_READY);
Thanks for your reply Dogbert!
I still can’t find a solution to this loading problem. I’m coding a small DJ application with 2 players. Imagine the user tries to load a huge file but decides to play another track while the sound is still loading. He has to wait till the end of the loading process to load another file. In the meantime the other player runs out of music…
I want to play sounds backwards so FMOD_CREATESTREAM is not an option. FMOD_CREATECOMPRESSEDSAMPLE would be an option because the loading time is relatively small, but I also want to play other supported formats and not only mp3s.
If someone has a hint for me it would be highly appreciated!!
Please login first to submit.