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 ?


  • You must to post comments
Best Answer

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.

  • You must to post comments

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.

  • Martin Cvengros

    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!

  • Martin Cvengros


    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 ?

  • Nicholas Wilcox

    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.

  • Martin Cvengros

    Thanks, email sent.

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.