sound.readData blocking call on error when streaming


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
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 ?


Firstly the starving check only applies to playing streams.

Can you give more details about your stream? I can’t repro a hang when a connection to a shoutcast server is closed while blocking in readData.

Hi Nicholas, thanks for reply !

I can live with starving flag being updated only for playing streams, no problem;

It could be reproduced on practically any stream I’ve tried while testing - for example on somafm:

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.

Thanks for looking into it once again!


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 ?

We don’t have anything for public uploads. You can host it yourself and send us the link to, or it’s small enough it can be sent as an attachment.

1 Like

Thanks, email sent.

We’ve reproduced the issue. We’re trying to find the best solution across all our platforms.

Edit: This will be fixed in 1.08.09 which will be released early August.

1 Like

Awesome, thanks for the info.

Updated post

1 Like