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 3413 - SDL & PulseAudio: Apps produce no sound, and freeze upon closing.
Summary: SDL & PulseAudio: Apps produce no sound, and freeze upon closing.
Status: RESOLVED ENDOFLIFE
Alias: None
Product: SDL
Classification: Unclassified
Component: audio (show other bugs)
Version: 2.0.4
Hardware: x86_64 Linux
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-25 13:05 UTC by reteo.varala
Modified: 2017-05-19 19:22 UTC (History)
1 user (show)

See Also:

Attachments
Backtrace of OpenXCom, which makes use of SDL 1.2, and demonstrates the issue. (579 bytes, text/plain)
2016-08-25 13:05 UTC, reteo.varala 		Details
Updated backtrace showing all available threads. (2.62 KB, text/plain)
2016-08-26 03:40 UTC, reteo.varala 		Details
Full backtrace of openxcom (2.83 KB, text/plain)
2016-08-26 03:54 UTC, reteo.varala 		Details
Full backtrace using all symbols (8.82 KB, text/plain)
2016-08-26 17:40 UTC, reteo.varala 		Details
Backtrace using "X Rebirth" (GOG version, uses SDL 2.0) with interrupt-based scheduling. (19.56 KB, text/plain)
2016-09-07 20:45 UTC, reteo.varala 		Details
Show Obsolete (3) 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 reteo.varala 2016-08-25 13:05:37 UTC 
Created attachment 2555 [details]
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.
Comment 1 Philipp Wiesemann 2016-08-25 20:41:28 UTC 
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.
Comment 2 reteo.varala 2016-08-26 03:40:26 UTC 
Created attachment 2556 [details]
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.
Comment 3 reteo.varala 2016-08-26 03:54:31 UTC 
Created attachment 2557 [details]
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.
Comment 4 reteo.varala 2016-08-26 17:40:52 UTC 
Created attachment 2558 [details]
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!
Comment 5 reteo.varala 2016-09-07 20:02:52 UTC 
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.
Comment 6 reteo.varala 2016-09-07 20:45:31 UTC 
Created attachment 2559 [details]
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.
Comment 7 reteo.varala 2016-09-07 20:47:29 UTC 
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.
Comment 8 reteo.varala 2016-10-01 15:36:16 UTC 
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.
Comment 9 reteo.varala 2016-10-29 14:23:39 UTC 
Updated, as the issue alternatively affects both 1.2.15 and 2.0.4, depending on which scheduling is set in PulseAudio.
Comment 10 Sam Lantinga 2016-10-31 02:23:35 UTC 
Ryan, can you look at this?
Comment 11 Ryan C. Gordon 2017-05-19 19:22:26 UTC 
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.