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

Added SDL_AUDIO_ALLOW_SAMPLES_CHANGE flag #2889

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

Added SDL_AUDIO_ALLOW_SAMPLES_CHANGE flag #2889

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.1
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2018-05-05 01:55:40 +0000, Anthony Pesch wrote:

Created attachment 3238
patch

Added SDL_AUDIO_ALLOW_SAMPLES_CHANGE flag enabling users of SDL_OpenAudioDevice to get the sample size of the actual hardware buffer vs having a stream created to handle the delta.

For my use case (an emulator), I would rather be aware of the buffer size mismatch and adjust how I run the emulator to ensure the correct amount of audio is generated vs creating the stream and imposing the additional processing.

On 2018-06-15 15:42:31 +0000, Ethan Lee wrote:

Adding a note to this patch to say that this is actually a necessary feature for certain WASAPI devices where, for reasons unknown, the device wants a buffer size that's a multiple of 528. I have to confirm this with my Xbox devs but this may even be mandatory on Xbox One!

On 2018-08-01 22:47:54 +0000, Ethan Lee wrote:

Adding one more note to point out that, at some point, SDL catches on to the fact that WASAPI is a weirdo and occasionally gets 528-sample blocks, but doesn't tell applications of this change. On UWP when you ask for a 1024-sample update, you will hit this assert:

https://hg.libsdl.org/SDL/file/abc706dbb7af/src/audio/SDL_audio.c#l667

And sure enough the device size/samples values are based on 528. So it almost seems like we have this partially done already, we just need to make it possible for applications to obtain this info when it hits us. Assuming this gets discovered at the right time, Anthony's patch should be able to fix the problem.

Unless applications 100% know what's going on ahead of time when dealing with WASAPI, this is kind of a massive blocker for Xbox.

On 2018-08-04 19:47:03 +0000, Ethan Lee wrote:

Poking this thread to confirm that this patch does fix the WASAPI bug for Windows, but not WinRT, since WinRT only activates the device and gets the buffer size after the device is opened and the thread is running. That's a separate WinRT bug though, for now this is basically required to not have Windows audio sound trashy and/or create buffer overflows.

On 2018-10-01 16:48:57 +0000, Sam Lantinga wrote:

I added this patch, but I'm wary about applications suddenly getting different values for samples that they don't expect. Let's try it out for now and see if that bites anybody.
https://hg.libsdl.org/SDL/rev/c68b05ca0761

If this turns out to be a problem we can simply remove it from SDL_AUDIO_ALLOW_ANY_CHANGE until SDL 2.1.

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

No branches or pull requests

1 participant