SDL_OpenAudioDevice format fallback and verification requirements

Determine whether SDL_OpenAudioDevice consistently reports the exact audio format used by the underlying device after opening, and whether developers must always verify the obtained format to avoid silent mismatches where the application writes samples in a format that differs from what the device actually expects.

The SDL documentation states that when the requested format is unavailable, SDL_OpenAudioDevice adjusts to the nearest supported format and stores the actual format in the provided SDL_AudioSpec structure. However, many tutorials omit a post‑open verification step, and on Android with SDL 2.0.14 a request for AUDIO_S16LSB was silently upgraded to AUDIO_F32LSB by the audio driver, producing no audible output unless the application checked the obtained format. Additionally, platform‑specific backends such as PulseAudio, CoreAudio, or OpenSL ES may introduce further format conversions that are not reflected in the SDL_AudioSpec unless explicitly queried.

Does SDL_OpenAudioDevice always update the SDL_AudioSpec with the exact format used by the backend, regardless of SDL version or audio backend? If the reported format differs from the requested format, is relying solely on the obtained format for sample data conversion sufficient, or must applications also query the backend directly? Are there known SDL versions where the fallback format is not correctly reflected in the SDL_AudioSpec, requiring additional checks beyond the structure?