sound.readData blocking call on error when streaming


(Martin Cvengros) #1

Hi,

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 ?

Thanks!


(Nicholas Wilcox) #2

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) #3

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: http://ice1.somafm.com/thetrip-128-mp3

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) #4

Hello,

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


(Nicholas Wilcox) #5

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


(Martin Cvengros) #6

Thanks, email sent.


(Nicholas Wilcox) #7

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.


(Martin Cvengros) #8

Awesome, thanks for the info.


(Nicholas Wilcox) #9

Updated post