You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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:
On 2018-06-15 15:42:31 +0000, Ethan Lee wrote:
On 2018-08-01 22:47:54 +0000, Ethan Lee wrote:
On 2018-08-04 19:47:03 +0000, Ethan Lee wrote:
On 2018-10-01 16:48:57 +0000, Sam Lantinga wrote:
The text was updated successfully, but these errors were encountered: