0
0

Hello,
with version 44.03, I have a new bug where FMOD stops playing any sound at all randomly. The symptom is that when I call playSound() with paused at true, and then calling setPaused(false) on the channel, it seems to stay in "paused" state (getDuration returns the correct info, but getPosition constantly returns 0). I checked my file system overrides and all my read operations are clean, and in 44.02, it works fine.

Simon

  • You must to post comments
0
0

Additionnaly, restarting the app does not seem to fix the issue. I have to reboot the computer to be able to play any more sounds.

  • You must to post comments
0
0

It seems that stopping / releasing the channel and sound and recreate them fix the issue most of the times. Maybe a threading issue occuring randomly on the first channel creation ?

  • You must to post comments
0
0

Can you give some more details of your hardware setup and how you’re using the API? Are you using WASAPI exclusive mode?

  • You must to post comments
0
0

Hi,
I use the default output on Surface RT as well as a default output on a laptop based on Ivy Bridge chipset.

my updates are called from the CompositionTarget.Render event, and my sounds are created with createStream, and my fileSystem implementation is async and is capable of working with any winrt IRandomAccessStream.

every sound creation is asynchronous and initiated on the UI thread. Every system::playSound as well.

the problem does not occur every time, and I don’t have a systematic repro. It seems to be timing related.

maybe I can send you a minidump of my process when I see it happen. Would that help?

Simon

  • You must to post comments
0
0

I sent you a PM with a dump file + debug output

Additionaly, I found that since 44.03 (maybe also in 44.02, I did not check that yet), the setStreamBufferSize is ignored (I set it at 32K, and I receive read requests of 2K).

It’s not to much of a problem, because my RandomAccessStream implementation has a read ahead algorithm, so it does basically nothing but copying smaller arrays of bytes more often. However, it is a bug, and there could be situations where it may break assumptions my code do have on how it will be called (I did add an assertion ensuring that the read request can be fullfilled by a single 64K buffer for exemple).

  • You must to post comments
0
0

For the setStreamBufferSize problem, it seems that the 2K requests are done only until FMOD finds the which codec to use. After that it’s ok, I get 2*32K read requests (which is what I expect).

  • You must to post comments
Showing 6 results
Your Answer

Please first to submit.