View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002130Dwarf FortressTechnical -- Soundpublic2010-06-02 08:022012-02-20 17:36
Reporteroliver Assigned Touser6 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionunable to reproduce 
Platformx86_64OSUbuntu Linux, 64-bitOS Version9.10
Product Version0.31.04 
Summary0002130: SOUND:YES consumes excessive CPU (runaway thread?)
DescriptionIf I start DF with [SOUND:YES], it uses one-and-a-bit cores worth of CPU while just sitting at the title screen:

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r b swpd free buff cache si so bi bo in cs us sy id wa
 4 0 0 84100 411228 1744428 0 0 32 23 340 729 24 4 72 1
 6 0 0 79752 411248 1748784 0 0 57 206 1153 6454 57 21 21 0
 5 0 0 79256 411260 1749384 0 0 66 11 1444 4185 61 15 23 0
 3 0 0 78884 411280 1749700 0 0 22 168 1539 4203 63 15 22 0

If I set [SOUND:NO], it uses much less CPU:

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r b swpd free buff cache si so bi bo in cs us sy id wa
 2 0 0 97308 411700 1758352 0 0 32 23 340 733 24 4 71 1
 2 0 0 96572 411716 1758932 0 0 58 182 1168 2557 28 1 70 1
 0 0 0 96200 411728 1759296 0 0 22 12 1100 2544 29 1 69 1
 1 0 0 188952 411748 1666528 0 0 19 14 1114 2597 28 1 70 1

This is a dual-core system. It seems like there's a runaway sound thread taking all the CPU it can, i.e. about one core's worth.
Additional InformationStartup with SOUND:YES reports:

...
Sound devices available:
ALSA Software
OSS Software
PulseAudio Software
Wave File Writer
Picking ALSA Software. If your desired device was missing, make sure you have the appropriate 32-bit libraries installed. If you wanted a different device, configure ~/.openalrc appropriately.
Perfect OpenAL context attributes GET
Loading bindings from data/init/interface.txt
...

Here's a thread dump of the case with SOUND:YES while it's chewing CPU. top says it's LWP 5630 (thread 2) that's the culprit - that thread is at 95% CPU or so, while the main thread is at 30% or so:

(gdb) thread apply all bt

Thread 5 (Thread 0xf4d8ab70 (LWP 5627)):
#0 0xf772a430 in __kernel_vsyscall ()
#1 0xf7039e96 in nanosleep () from /lib32/libc.so.6
#2 0xf76cbf47 in SDL_Delay () from /usr/lib32/libSDL-1.2.so.0
#3 0xf76cbf94 in ?? () from /usr/lib32/libSDL-1.2.so.0
#4 0xf767ea6e in ?? () from /usr/lib32/libSDL-1.2.so.0
#5 0xf76c8d2d in ?? () from /usr/lib32/libSDL-1.2.so.0
#6 0xf6f8d80e in start_thread () from /lib32/libpthread.so.0
#7 0xf7070b4e in clone () from /lib32/libc.so.6

Thread 4 (Thread 0xf4589b70 (LWP 5628)):
#0 0xf772a430 in __kernel_vsyscall ()
#1 0xf6f94355 in sem_wait@@GLIBC_2.1 () from /lib32/libpthread.so.0
#2 0xf76c8e18 in SDL_SemWait () from /usr/lib32/libSDL-1.2.so.0
#3 0xf7243395 in enablerst::async_loop() () from /home/oliver/df_31_04/df_linux/libs/libgraphics.so
#4 0xf724384d in call_loop(void*) () from /home/oliver/df_31_04/df_linux/libs/libgraphics.so
#5 0xf767ea6e in ?? () from /usr/lib32/libSDL-1.2.so.0
#6 0xf76c8d2d in ?? () from /usr/lib32/libSDL-1.2.so.0
#7 0xf6f8d80e in start_thread () from /lib32/libpthread.so.0
#8 0xf7070b4e in clone () from /lib32/libc.so.6

Thread 3 (Thread 0xefbaeb70 (LWP 5629)):
#0 0xf772a430 in __kernel_vsyscall ()
#1 0xf7062ed6 in poll () from /lib32/libc.so.6
#2 0xf3cdccc2 in ?? () from /usr/lib32/libpulse.so.0
#3 0xf3cc9e09 in pa_mainloop_poll () from /usr/lib32/libpulse.so.0
#4 0xf3ccbc23 in pa_mainloop_iterate () from /usr/lib32/libpulse.so.0
#5 0xf3ccbcf4 in pa_mainloop_run () from /usr/lib32/libpulse.so.0
#6 0xf3cdcbc3 in ?? () from /usr/lib32/libpulse.so.0
#7 0xf3c24ac2 in ?? () from /usr/lib32/libpulsecommon-0.9.19.so
#8 0xf6f8d80e in start_thread () from /lib32/libpthread.so.0
#9 0xf7070b4e in clone () from /lib32/libc.so.6

Thread 2 (Thread 0xef3adb70 (LWP 5630)):
#0 0xf772a430 in __kernel_vsyscall ()
#1 0xf7062ed6 in poll () from /lib32/libc.so.6
#2 0xf6f0ae15 in ?? () from /usr/lib32/libasound.so.2
#3 0xf6f0afe3 in snd_pcm_wait () from /usr/lib32/libasound.so.2
#4 0xf6f0b17b in ?? () from /usr/lib32/libasound.so.2
#5 0xf6f4fe7a in ?? () from /usr/lib32/libasound.so.2
#6 0xf6f059bc in snd_pcm_writei () from /usr/lib32/libasound.so.2
#7 0xf69261db in ?? () from /usr/lib32/libopenal.so.1
#8 0xf6921492 in ?? () from /usr/lib32/libopenal.so.1
#9 0xf6f8d80e in start_thread () from /lib32/libpthread.so.0
#10 0xf7070b4e in clone () from /lib32/libc.so.6

Thread 1 (Thread 0xf4f62740 (LWP 5626)):
#0 0xf772a430 in __kernel_vsyscall ()
#1 0xf7039e96 in nanosleep () from /lib32/libc.so.6
#2 0xf76cbf47 in SDL_Delay () from /usr/lib32/libSDL-1.2.so.0
#3 0xf7245488 in enablerst::do_frame() () from /home/oliver/df_31_04/df_linux/libs/libgraphics.so
#4 0xf7245659 in enablerst::eventLoop_SDL() () from /home/oliver/df_31_04/df_linux/libs/libgraphics.so
#5 0xf72462c0 in enablerst::loop(std::string) () from /home/oliver/df_31_04/df_linux/libs/libgraphics.so
#6 0xf7246b02 in main () from /home/oliver/df_31_04/df_linux/libs/libgraphics.so
#7 0xf6fb8b56 in __libc_start_main () from /lib32/libc.so.6
#8 0x0804dec1 in ?? ()
TagsSDL-only

Relationships

related to 0002616 resolvedBaughn Initializing OpenAL failed, no sound will be played (bundled libsndfile.so doesn't work, system libsndfile does) 
related to 0002421 resolveduser6 Using the native Linux SDL release v0.31.08 The game crashes on exit 
related to 0002520 resolvedLogical2u While running DF and the music player foobar2000 in the background, the music stutters/hangs randomly for a moment 

Activities

oliver

2010-07-10 21:12

reporter   ~0009909

This is still present in 0.31.09.

I've worked out two ways to consistently reproduce it:

a) have two sound devices running through pulseaudio, and set the system sound output device to "simultaneous output" before starting DF; or
b) change the output device from one device to the other while DF is running (sound switches, but CPU spikes)

It also correlates with crackle in playback - i.e. if I get crackle, then it'll be chewing lots of CPU.

Box

2010-07-12 22:16

reporter   ~0010099

Could this be leading to other problems on Windows? After running dwarf fortress for about 40 minutes I started getting lock-ups from the System process eating up 95~98% of the processing power. Was forced to kill the process, but even then it didn't let up, so I gave the computer a restart.

Could this be related at all?

user6

2012-02-20 17:36

  ~0020304

Please reopen this report or PM me on the forums if this bug is still present in 0.34.02.

Issue History

Date Modified Username Field Change
2010-06-02 08:02 oliver New Issue
2010-06-21 11:33 user6 Additional Information Updated
2010-06-21 11:38 user6 Tag Attached: SDL-only
2010-06-25 21:45 user6 Relationship added related to 0002421
2010-06-29 07:38 user6 Category Technical => Technical -- General
2010-07-10 21:12 oliver Note Added: 0009909
2010-07-11 10:35 user6 Relationship added related to 0002520
2010-07-12 22:16 Box Note Added: 0010099
2010-07-18 02:04 user6 Relationship added related to 0002616
2010-07-18 02:05 user6 Category Technical -- General => Technical -- Sound
2012-02-20 17:36 user6 Note Added: 0020304
2012-02-20 17:36 user6 Status new => resolved
2012-02-20 17:36 user6 Resolution open => unable to reproduce
2012-02-20 17:36 user6 Assigned To => user6