Answered
0
0

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!

  • You must to post comments
Best Answer
1
0

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

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

    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

    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

    Thanks, email sent.

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.