Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[raudio] (Bug) Audio is cut and never resumes if Windows goes into sleep #3535

Closed
michelelorusso05 opened this issue Nov 13, 2023 · 3 comments
Labels
external This issue depends on external lib

Comments

@michelelorusso05
Copy link

I am using a custom AudioStream to play audio in my emulator. However, I noticed that if the computer goes in sleep mode while the emulator is running, once the computer has booted back up the program will have no audio whatsoever and there is no chance of it coming back; only closing and reopening the emulator works.

I am initializing a custom audio stream with LoadAudioStream() and then manipulating it by calling SetAudioStreamCallback() with a custom function that populates the audio frames.

Is there a function that lets me detect the standby state to close the stream and to open a new one? Or am I missing something?

@raysan5
Copy link
Owner

raysan5 commented Nov 13, 2023

@michelelorusso05 It sounds like an issue with the device re-initialization after sleep, not sure if this scenario is contemplated by miniaudio... Maybe @mackron could provide more info?

@mackron
Copy link
Contributor

mackron commented Nov 13, 2023

This is related to this miniaudio issue: mackron/miniaudio#717

If this is critical to you, consider adding MA_NO_WASAPI to your build settings. That will disable the WASAPI backend and force the DirectSound backend which I believe works. Alternatively, if there's a way for you to detect the computer going to sleep and waking up, you can manually handle this at a higher level than miniaudio and manually uninitialize and reinitialize miniaudio from there. This is not something I consider super high priority so it might be a while before I get to addressing this at the miniaudio level.

@raysan5
Copy link
Owner

raysan5 commented Nov 14, 2023

@mackron thank you very much for the reply and the details on the issue.

@michelelorusso05 It seems this issue is related to miniaudio and low-priority, you can try the approach proposed or wait for a potential fix in the future. I'm closing the issue on raylib side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external This issue depends on external lib
Projects
None yet
Development

No branches or pull requests

3 participants