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 3858 - Sound issues with SDL 2.0.6
Summary: Sound issues with SDL 2.0.6
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: audio (show other bugs)
Version: 2.0.6
Hardware: x86 Other
: P2 blocker
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-02 21:12 UTC by Simon Howard
Modified: 2017-11-01 04:43 UTC (History)
5 users (show)

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 Simon Howard 2017-10-02 21:12:16 UTC 
Please see these bug reports for details:

https://github.com/chocolate-doom/chocolate-doom/issues/945
https://github.com/bradharding/doomretro/issues/410

I'm seeing conflicting reports that SDL either crashes or plays no sound with that SDL 2.0.6 (2.0.5 does not have this problem).

Using a larger audio buffer appears to resolve the problem, but it would be good if it was fixed on the SDL side. Apparently a new SDL_mixer release might also fix the problem?
Comment 1 Sam Lantinga 2017-10-02 22:41:36 UTC 
Ryan, can you look at this ASAP?
Comment 2 Ozkan Sezer 2017-10-03 05:40:00 UTC 
Can this be related to bug #3848 or bug #3849? (Haven't looked at your code.)
Comment 3 David Carlier 2017-10-03 06:50:00 UTC 
Hi here the person who posted the error on GitHub.
It seems very likely it is, got a segmentation fault for similar reason, the 3849 leads me to think I was not extremely far from the truth.
Comment 4 David Carlier 2017-10-03 07:00:25 UTC 
On Arch Linux, unlike Debian based distros, there is no separated packages with debug symbols but I started to have a look at the code and it seems there is quite a change between 2.0.5 and 2.0.6 ... could this be, somewhat, related to it ?

http://hg.libsdl.org/SDL/file/8df7a59b5528/src/audio/SDL_audiocvt.c#l807
Comment 5 janisozaur 2017-10-04 09:28:49 UTC 
bug #3848 and bug #3849 do cover both issues spotted in 2.0.6 release. I think this report can be considered a duplicate of those two.
Comment 6 Justin Jacobs 2017-10-11 03:02:46 UTC 
I think I've also encountered this bug. I've posted a trace here: https://github.com/clintbellanger/flare-engine/issues/1516#issuecomment-335667432

It appears that this bug happens when resampling sounds from high -> low frequencies. In our case, we're going from 44100Hz to 22050Hz. Using a higher frequency for Mix_OpenAudio() results in no crash.
Comment 7 Sam Lantinga 2017-10-12 15:43:05 UTC 
Can you check to see if this is fixed in the latest snapshot?
http://www.libsdl.org/tmp/SDL-2.0.zip

Thanks!
Comment 8 Justin Jacobs 2017-10-12 16:12:58 UTC 
The issue I was having appears to have been fixed in that snapshot. Nice work!
Comment 9 Ryan C. Gordon 2017-10-12 16:18:01 UTC 
I think this is fixed along with the other mentioned reports, so I'm resolving this bug.

--ryan.
Comment 10 Simon Howard 2017-10-27 17:19:11 UTC 
Multiple reports from Chocolate Doom users are that this is still not fixed.

<https://github.com/chocolate-doom/chocolate-doom/issues/945>
Comment 11 Eric Wasylishen 2017-10-30 02:44:50 UTC 
It looks like a bug in Chocolate Doom (buffer passed to SDL_ConvertAudio is smaller than the required len*len_mult), see my comment on https://github.com/chocolate-doom/chocolate-doom/issues/945
Comment 12 David Carlier 2017-10-31 09:59:34 UTC 
The question is, since the change from SDL_memcpy to SDL_memmove did not fully fix it (I think personally it s a good change to keep), and if the code consumers really need to allocate more memory than with versions <= 2.0.6, assuming it is intended and not a edgy bug, would it be relevant to mention it in changelogs, relevant C header file ... ? because not obvious unless you read the source code to realise it has been rewritten :-)
Comment 13 Simon Howard 2017-11-01 04:43:52 UTC 
#11 is correct. It looks like this was indeed a bug in Chocolate Doom, albeit one that appears to only have been exposed due to the recent audio changes.

A fix has now been merged in Chocolate Doom.