We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 5094 - PulseAudio backend should default to native source/sink parameters
Summary: PulseAudio backend should default to native source/sink parameters
Status: NEW
Alias: None
Product: SDL
Classification: Unclassified
Component: audio (show other bugs)
Version: 2.0.12
Hardware: x86_64 Linux
: P2 enhancement
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-14 22:40 UTC by Daniel Glöckner
Modified: 2020-04-14 22:40 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Glöckner 2020-04-14 22:40:52 UTC 
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.