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 2952 - SDL_MixAudioFormat does not support audio format AUDIO_U16LSB/AUDIO_U16MSB
Summary: SDL_MixAudioFormat does not support audio format AUDIO_U16LSB/AUDIO_U16MSB
Status: RESOLVED WORKSFORME
Alias: None
Product: SDL
Classification: Unclassified
Component: audio (show other bugs)
Version: 2.0.2
Hardware: x86_64 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.12
Depends on:
Blocks:
 
Reported: 2015-04-20 19:05 UTC by Simon Sandström
Modified: 2019-09-20 20:48 UTC (History)
3 users (show)

See Also:

Attachments
Testcase that works on Windows Mingw64 but fails on Ubuntu 18.04 (924.25 KB, application/x-zip-compressed)
2018-11-03 04:00 UTC, WallyZ 		Details
View All 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 Simon Sandström 2015-04-20 19:05:16 UTC 
As stated in Summary. The switch statement will execute the default case and set a SDL error message: "SDL_MixAudio(): unknown audio format".


There are atleast two more problems here:

1. SDL_MixAudioFormat does not notify the user that an error has occured and that a SDL error message was set. It took me awhile to understand why I couldn't mix down the volume on my AUDIO_U16LSB formatted audio stream.. until I started digging in the SDL source code.

2. The error message is incorrect, it should read: "SDL_MixAudioFormat(): unknown audio format".


Reproduced with SDL 2.0.2 on Debian Jessie:

$ apt-cache policy libsdl2-dev
libsdl2-dev:
  Installed: 2.0.2+dfsg1-6
  Candidate: 2.0.2+dfsg1-6
  Version table:
 *** 2.0.2+dfsg1-6 0
        500 http://ftp.acc.umu.se/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status
$ uname -a
Linux debian-testing-vm 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-2 (2015-04-13) x86_64 GNU/Linux
Comment 1 saurabh tiwari 2015-08-03 10:46:08 UTC 
Facing the same issue.
Any plan to fix this?
Comment 2 Sam Lantinga 2016-10-08 00:23:41 UTC 
Fixed, thanks!
https://hg.libsdl.org/SDL/rev/f660a6ed9dcf
Comment 3 WallyZ 2018-11-03 04:00:39 UTC 
Created attachment 3435 [details]
Testcase that works on Windows Mingw64 but fails on Ubuntu 18.04

make the code

To execute

$ ./sdlaudio(.exe) 

plays audio2.wav

$ ./sdlaudio(.exe) r

plays audio2.raw
Comment 4 WallyZ 2018-11-13 07:54:33 UTC 
I suspect there to be an underlying problem in SDL_audio as these same two audio formats do not work under Linux using SDL2 (2.0.8) basic audio.

When the same code base is compiled on MINGW under windows the code works fine.

Under Linux the SDL_OpenAudioDevice succeeds, returns a valid deviceID but refuses to play these formats.  A comparison of the requested format vs obtained format also shows no discrepancies.
Comment 5 Ryan C. Gordon 2019-07-30 17:49:36 UTC 
(Sorry if you get several emails like this, we're marking a bunch of bugs.)

We're hoping to ship SDL 2.0.11 on a much shorter timeframe than we have historically done releases, so I'm starting to tag bugs we hope to have closed in this release cycle.

Note that this tag means we just intend to scrutinize this bug for the 2.0.11 release: we may fix it, reject it, or even push it back to a later release for now, but this helps give us both a goal and a wishlist for the next release.

If this bug has been quiet for a few months and you have new information (such as, "this is definitely still broken" or "this got fixed at some point"), please feel free to retest and/or add more notes to the bug.

--ryan.
Comment 6 Ryan C. Gordon 2019-09-04 04:22:16 UTC 
It's possible we fixed this since 2018, but this definitely works on Ubuntu 18.04 here, both with the PulseAudio and ALSA targets.

--ryan.
Comment 7 Ryan C. Gordon 2019-09-20 20:47:35 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.
Comment 8 Ryan C. Gordon 2019-09-20 20:48:40 UTC 
We're changing how we do SDL release versions; now releases will be even numbers (2.0.10, 2.0.12, etc), and as soon as we tag a release, we'll move the internal version number to an odd number (2.0.12 ships, we tag the latest in revision control as 2.0.13 immediately, which will become 2.0.14 on release, etc).

As such, I'm moving the bugs tagged with target-2.0.11 to target 2.0.12. Sorry if you get a lot of email from this change!

Thanks,
--ryan.