Hi,
I’m using c# integrations in Unity and need it to be as reliable as possible with audio streamed from the network.
Currently, there is one situation which cannot be resolved automatically (and I need to - unfortunately - inform the user that application will potentially hang and will have to be manually restarted - which, undoubtely, is not very user friendly)
Problem is that in certain state it’s not possible to release the sound, and system, due to FMOD deadlocking on release.
This can be reliably triggered by for example hinting wrong (FMOD.SOUND_TYPE.MPEG) sound type for a stream which is in e.g. Ogg Vorbis format in suggestedsoundtype in CREATESOUNDEXINFO when creating sound.
Sound::getOpenState then reports FMOD.OPENSTATE.BUFFERING indefinitely, and an attempt for releasing it after a while results in FMOD deadlocking;
(If no attempt to relase the sound is made, but stream wants to restart again, Sound::getOpenState then reports FMOD.OPENSTATE.LOADING indefinitely.)
this setup is deliberately misconfigured just to illustrate the point ( when e.g. FMOD.SOUND_TYPE.UNKNOWN is hinted in CREATESOUNDEXINFO, FMOD autodetects the format without problems and creates sound which can be released etc.), but I believe that under various network conditions the attempt to release the sound might and will ) come in the least convenient time ( i.e. when get Sound::getOpenState would report FMOD.OPENSTATE.BUFFERING or FMOD.OPENSTATE.LOADING) and leading to release problems nevertheless, despite the fact that createSound parameters were configured correctly.
Do you think this issue is worth reporting (where?).
I have been unable to reproduce your results both in and out of Unity.
What version of FMOD are you using?
Can you paste the code snippets of where you are recreating this issue?
ah right, it’s probably rather specific:
I’m feeding AudioSource via OnAudioFilterRead with sound.readData from the stream - I’ll post isolated code later; using latest 1.10.00
It tries to stream an ogg radio, but fails due to extInfo.suggestedsoundtype being set to FMOD.SOUND_TYPE.MPEG on line 44, and subsequently fails to release sound.
If you change it to OGGVORBIS or UNKNOWN you’ll see that it plays and can be stopped.
Let me know if this makes sense, hopefully this helps!
Using the FMOD.MODE.MPEGSEARCH flag with netstream is the main thing causing the game to hang. This flag tells the system to read the entire file, which for a netstream is forever. I’m assuming you set this flag specifically for iOS, but is not required if you set the suggested sound type, as you have. This will fix the issue for MPEG.
There will still be an issue when using something other than MPEG, due to the block size set in the file system. Suggested sound type gives the system a starting point and MPEG is normally last because it uses two blocks of 2048 to determine if the file is MPEG. The problem is that the first block gets thrown away when it gets the second, but if the file is not MPEG it will attempt to seek back to the start of the first block that is now gone.
To avoid this, you can increase the block size in your system.setFileSystem() call to something much larger (eg.16*1024).
Lastly, these are more thoughts and not crucial to fixing the issue you mentioned, remove the flags IGNORETAGS and OPENONLY. If the stream is MPEG and has tags, this will tell the system where the start of the sound is, otherwise it will be searching through the tag data (if it has any). OPENONLY is generally used in conjunction with system.readData and just opens the file nothing else.