When an application passes 0 in one of the SDL_AudioSpec fields, prepare_audiospec chooses default values that the PulseAudio backend passes to the server. The server will happily obey and convert the audio data when the hardware can't deal with these settings. Usually our game is played by people with sound hardware that captures its audio input with a stereo ADC. But some people want to use more professional equipment that captures f.ex. six microphones in one audio stream. If our application asks for two channels, the additional channels of the professional equipment are inaccessible. If we ask for 6 channels, the data from the consumer hardware gets remixed into a 5.1 stream.

What I as a user of the API would expect is that a 0 in one of the SDL_AudioSpec fields leads to a settings that avoids audio conversion in software. The same can be said about the allowed_changes parameter of SDL_OpenAudioDevice. To me these flags are an invitation to use the settings with the least overhead.

In the PulseAudio backend the format with the least overhead is probably the one mentioned in the sample_spec field of the pa_sink_info/pa_source_info structures. The backend already asks for these structures to determine the name of the device.