This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Backtrace of OpenXCom, which makes use of SDL 1.2, and demonstrates the issue. (OpenXcom-backtrace.txt, text/plain, 2016-08-25 13:05:37 +0000, 579 bytes)
• Updated backtrace showing all available threads. (Backtraces.txt, text/plain, 2016-08-26 03:40:26 +0000, 2683 bytes)
• Full backtrace of openxcom (Backtraces.txt, text/plain, 2016-08-26 03:54:31 +0000, 2897 bytes)
• Full backtrace using all symbols (Backtraces.txt, text/plain, 2016-08-26 17:40:52 +0000, 9036 bytes)
• Backtrace using "X Rebirth" (GOG version, uses SDL 2.0) with interrupt-based scheduling. (XRebirth-Backtrace.txt, text/plain, 2016-09-07 20:45:31 +0000, 20025 bytes)

Reported in version: 2.0.4
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2016-08-25 13:05:37 +0000, wrote:

Created attachment 2555
Backtrace of OpenXCom, which makes use of SDL 1.2, and demonstrates the issue.

I know that the current version of SDL is 2, but there are a lot of programs I use that still make use of the old API, so I figured it wouldn't hurt submitting a bug report.

Any time I run an application that uses SDL 1.2 while PulseAudio is running, it will produce no sound, and instantly freeze when I attempt to close it. The window will remain frozen until I either kill -9 the app, or shut down PulseAudio.

This issue has occurred on two instances of Ubuntu (Wily and Xenial), as well as a fresh Gentoo installation. I am currently using PulseAudio 8 and the SDL version is 1.2.15. The system is AMD64.

I've included a backtrace on one such program, OpenXcom. Please let me know if anything else might help.

On 2016-08-25 20:41:28 +0000, Philipp Wiesemann wrote:

From the backtrace it looks like the main thread is waiting for the audio thread to finish.

A backtrace of the audio thread might be useful.

On 2016-08-26 03:40:26 +0000, wrote:

Created attachment 2556
Updated backtrace showing all available threads.

Ah, gotcha. I didn't realize there were multiple threads, because "thread 2" returned an error. Took me a few minutes to figure out how to list threads, but I have the updated backtraces added. P[lease let me know if anything else is needed.

On 2016-08-26 03:54:31 +0000, wrote:

Created attachment 2557
Full backtrace of openxcom

Here's a better backtrace. I apologize for the mistakes; I'm still pretty new at reporting bugs, and am still getting familiar with gdb.

On 2016-08-26 17:40:52 +0000, wrote:

Created attachment 2558
Full backtrace using all symbols

Okay, after a night of recompiling most of the libraries to use debugging symbols, here is the backtrace with all the details that can be squeezed out (that I'm currently aware of). I hope this helps!

On 2016-09-07 20:02:52 +0000, wrote:

I just made a discovery; apparently, while solving an issue with glitchy sound through Spotify, I found a workaround to allow SDL 1.2 programs to work without silence or freezing, while keeping Pulse the primary audio driver.

Apparently, recent versions of Pulseaudio use a timer-based form of audio scheduling that is responsible for a number of audio glitches on my system. By adding "tsched=0" to the "load-module module-udev-detect" line (thereby changing the daemon from "timer-driven" to "interrupt-driven"), the problem goes away. Since this is not the default setting for PulseAudio for most distributions.

I'm not sure if this is a good solution, though, but it is a workaround, and it might just point to the source of the problem with SDL 1.2 software freezing.

On 2016-09-07 20:45:31 +0000, wrote:

Created attachment 2559
Backtrace using "X Rebirth" (GOG version, uses SDL 2.0) with interrupt-based scheduling.

I've attached a backtrace for "X Rebirth", a game I purchased through GOG; as is the case with OpenXCOM, the game is silent, and freezes on shutdown, but unlike OpenXCom (which has problems with timer-based scheduling), it only happens on interrupt-based scheduling.

I don't know if this helps, but I hope so.

On 2016-09-07 20:47:29 +0000, wrote:

Just to clarify; when Pulse is set to interrupt-based scheduling, SDL 1.2 software will work with Pulse. If Pulse is set to timer-based scheduling, SDL 2.0 software will work with pulse. There is no way to make both work with pulse at the same time without changing the scheduling and resetting Pulse when changing programs.

On 2016-10-01 15:36:16 +0000, wrote:

Updated the title to reflect the current issue. Although thought I'd simplify the issue explanation in this comment.

The short of it is this: SDL 1.2 programs are silent and freeze upon closing when Pulse is set to timer-based scheduling. SDL 2.0 programs are silent and freeze upon closing when Pulse is set to interrupt-based scheduling.

On 2016-10-29 14:23:39 +0000, wrote:

Updated, as the issue alternatively affects both 1.2.15 and 2.0.4, depending on which scheduling is set in PulseAudio.

On 2016-10-31 02:23:35 +0000, Sam Lantinga wrote:

Ryan, can you look at this?

On 2017-05-19 19:22:26 +0000, Ryan C. Gordon wrote:

Not to be unhelpful, but the SDL2 program (X Rebirth) is using OpenAL and not SDL's audio code. My assumption is our 1.2 code is probably bitrotting, but is okay in 2.0.

--ryan.