| Summary: | Added SDL_AUDIO_ALLOW_SAMPLES_CHANGE flag | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Anthony Pesch <inolen> |
| Component: | audio | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | flibitijibibo, sezeroz |
| Version: | HG 2.1 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Attachments: | patch | ||
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! 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. 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. 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. |
Created attachment 3238 [details] 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.