libsdl-org/sdl2-compat

testautomation --filter audio_pauseUnpauseAudio

slouken opened this issue · 6 comments

slouken commented

This test fails in sdl2-compat.

It looks like it's unpausing the audio and expecting the audio callback to run in the background. That works as expected in SDL2, but for some reason that's not happening in SDL3.

icculus commented

This is passing in sdl2-compat for me, with the latest in main for SDL3 and sdl2-compat. Is there a specific audio backend you're using? I could see this maybe failing on one that provides its own thread.

slouken commented

I think I'm using wasapi

  • 👍1
icculus commented

This reproduces for me on Windows, now that I've got everything building.

icculus commented

Okay, here's what's happening:

sdl2-compat exposes a single SDL3 audio stream as an SDL2 audio device, bridging the SDL3 stream's callback to the app's SDL2 audio callback.

The stream will fire the callback whenever something (here, the SDL3 audio device's thread) requests more data. It tells the app roughly how much more it needs. If it doesn't need anything, because the stream has enough data to fulfill the current request, it fires the callback asking for 0 more bytes of data.

This 0 is what's upsetting the test. WASAPI is triggering this, but having not looked further, I assume any platform could trigger this, depending on hardware settings and application needs.

So there are several good options for fixing this that can have further effects than sdl2-compat:

  1. We just ignore 0-byte requests in sdl2-compat and call it a day.

  2. We change the SDL3 audio stream callback to only fire when something reads from a stream and the stream needs more data to fulfill the request. Right now it always fires, in case the app wants the status update, since the app isn't required to fulfill a request of any size here, in any case, but that might be silly.

  3. We could have sdl2-compat manage the SDL2 callback itself and feed the audio stream at a consistent rate, and not use the audio stream callback at all.

  4. We could wait to fix this until we add a postmix callback to each logical device in SDL3, which would probably map much more closely to SDL2's audio callback, and make sdl2-compat use that instead. If this gets added, it's going to be unforgiving about data conversion and such, because we just built a whole fancy layer on top of it to handle that. But that would be sdl2-compat's problem, not the SDL2-based app's.

I'm leaning towards 4 at the moment, since we're in theory going to want this for SDL_mixer, and other things.

icculus commented

(Actually, something else is going on, too, because it's taking more than a second to need more than 0 bytes of audio, which also causes the test to fail when ignore 0-byte requests...that part might be an sdl2-compat bug for sure; I'm guessing we need to throw away already-queued data when pausing the SDL2 device.)

icculus commented

The requests for 0 bytes of audio was a stupid logic error in SDL3, fixed now:

libsdl-org/SDL@0714da3

Which resolves this bug, as the test no longer fails on WASAPI.

And I've pushed some defensive fixes to sdl2-compat that I mentioned. I'll move the other thoughts over to another bug and close this one.