I’m using the low level API C# wrapper in Unity to manually drive the streaming, such that:
just a call to createSound
no playSound and no getChannel calls
manually retrieving decoded stream via sound.readData
in a separate thread.
Works almost for all situations as intended, except
getOpenState starving flag is unreliable (is not set) in this case - I’m using a workaround by monitoring the buffer percentage ( not, unfortunately 100% reliable, too ) but what is worse
sound.readData blocks on stream error - i.e. when the network is lost, or file playback is finished.
On Windows, it seems like it is blocking on WaitForSocketcall and never / until a timeout expires returns.
Is there a way to inspect the stream condition other than by calling ‘getOpenState’ and / or a way to for sound.readDatato actually return proper error code when there’s no data available in this scenario ?
One note though: the readData is called on different thread than main thread.
– i suppose that might be the problem.
( Unity has a special audio thread callback where current raw audio buffer can be accessed - I am using it to fill audio buffer with decoded stream data - it works without problems, except when the stream breaks… )
I wanted to test directly from e.g. netstream sample without c# wrapper, but I assumed that it would probably behave the same.
If you fail to reproduce it again, I will try to setup FMOD5 test case.
I’ve managed to strip down everything to ~ 300 LOC and a single MonoBehaviour ( it’s basically adapted net_stream from FMOD Studio API Windows lowlevel samples ).
It’s reproducible every time the network disappears ( meaning physically unplugging the network cord / turning off WiFi, until the buffer is starved )
Tested with Unity 5.1 and 5.3 in the editor and win64 standalone builds.
Is there any way to possibly send a repro case / some other approriate way ?