You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
On 2017-10-02 22:41:36 +0000, Sam Lantinga wrote:
Ryan, can you look at this ASAP?
On 2017-10-03 05:40:00 +0000, Ozkan Sezer wrote:
Can this be related to bug # 3848 or bug # 3849? (Haven't looked at your code.)
On 2017-10-03 06:50:00 +0000, David Carlier wrote:
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.
On 2017-10-03 07:00:25 +0000, David Carlier wrote:
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 ?
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.
On 2017-10-30 02:44:50 +0000, Eric Wasylishen wrote:
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 chocolate-doom/chocolate-doom#945
On 2017-10-31 09:59:34 +0000, David Carlier wrote:
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 :-)
On 2017-11-01 04:43:52 +0000, Simon Howard wrote:
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.
The text was updated successfully, but these errors were encountered:
This bug report was migrated from our old Bugzilla tracker.
Reported in version: 2.0.6
Reported for operating system, platform: Other, x86
Comments on the original bug report:
On 2017-10-02 21:12:16 +0000, Simon Howard wrote:
On 2017-10-02 22:41:36 +0000, Sam Lantinga wrote:
On 2017-10-03 05:40:00 +0000, Ozkan Sezer wrote:
On 2017-10-03 06:50:00 +0000, David Carlier wrote:
On 2017-10-03 07:00:25 +0000, David Carlier wrote:
On 2017-10-04 09:28:49 +0000, janisozaur wrote:
On 2017-10-11 03:02:46 +0000, Justin Jacobs wrote:
On 2017-10-12 15:43:05 +0000, Sam Lantinga wrote:
On 2017-10-12 16:12:58 +0000, Justin Jacobs wrote:
On 2017-10-12 16:18:01 +0000, Ryan C. Gordon wrote:
On 2017-10-27 17:19:11 +0000, Simon Howard wrote:
On 2017-10-30 02:44:50 +0000, Eric Wasylishen wrote:
On 2017-10-31 09:59:34 +0000, David Carlier wrote:
On 2017-11-01 04:43:52 +0000, Simon Howard wrote:
The text was updated successfully, but these errors were encountered: