FMOD stuck waiting forever in sem_wait() on shutdown with some Linux/ALSA systems


I develop a third party viewer for Second Life and have been using FMOD for years in it.

With FMOD Studio, I am seeing some weird things happening under some Linux systems (so far, could only reproduce in Linux VirtualBox VMs configured to use ALSA as the audio back-end).

On these systems, while FMOD reports a successful initialization and opening of an ALSA output, no sound is produced at all, and when shutting down the application, FMOD stays stuck forever in FMOD::System::close(), waiting for a semaphore in libpthread’s sem_wait().

Here is the log and backtrace I get under gdb:
2020-11-06T21:50:56Z INFO: LLAudioEngine::init: Audio engine successfully initialized with 30 channels.
2020-11-06T21:50:57Z INFO: LLAudioEngine_FMOD::init: ALSA output initialized
2020-11-06T21:50:57Z INFO: LLAudioEngine_FMOD::init: FMOD device: default:CARD=Intel with parameters: 48000 Hz, 2 channels - Buffers: 4 * 1024 bytes - Latency: 85ms.
2020-11-06T21:50:57Z INFO: LLStartUp::startAudioEngine: Audio engine initialized.
…/… <-at this point I close the viewer application
2020-11-06T21:51:13Z INFO: LLStartUp::shutdownAudioEngine: Deleting existing audio engine instance
2020-11-06T21:51:13Z INFO: LLAudioEngine_FMOD::shutdown: Shutting down the audio engine…
2020-11-06T21:51:13Z INFO: LLAudioEngine_FMOD::shutdown: Closing FMOD Studio
2020-11-06T21:51:15Z INFO: ll_cleanup_apr: Cleaning up APR <-at this point the viewer finished cleaned up its structures and should exit
Program received signal SIGINT, Interrupt.
0x0000003dbb40d8b0 in sem_wait () from /lib64/
(gdb) bt
#0 0x0000003dbb40d8b0 in sem_wait () at /lib64/
#1 0x00007ffff7598739 in () at /usr/local/CoolVLViewer-1.28.0/lib/
#2 0x00007ffff7597c47 in () at /usr/local/CoolVLViewer-1.28.0/lib/
#3 0x00007ffff7569097 in () at /usr/local/CoolVLViewer-1.28.0/lib/
#4 0x00007ffff758e2d6 in () at /usr/local/CoolVLViewer-1.28.0/lib/
#5 0x00007ffff7583e94 in FMOD::System::close() () at /usr/local/CoolVLViewer-1.28.0/lib/
#6 0x00000000011195de in LLAudioEngine_FMOD::shutdown() (this=) at indra/llaudio/llaudioengine_fmod.cpp:394
#7 0x00007fff00000000 in ()
#8 0x00007fffffffd890 in ()
#9 0x00000000026db910 in ()
#10 0x00007ffff6249a90 in ()
#11 0x0000000000d072d0 in LLStartUp::shutdownAudioEngine() () at indra/newview/llstartup.cpp:378
#12 0x00007fff00000000 in ()
#13 0x00007ffff62ab280 in ()
#14 0x00007ffff6249a90 in ()
#15 0x00007ffff6249a90 in ()
#16 0x00000000006984c3 in LLAppViewer::cleanup() (this=) at indra/newview/llappviewer.cpp:1961
#17 0x0000000000000000 in ()
(gdb) quit

To me, it feels a bit like if FMOD somehow queued the sounds for playback and was waiting for the queue to empty before closing down. Since no sound is output, it would wait forever…

Hi sldev,

Thanks for the information. We have identified the hang issue and have a fix that will be included in 2.00.15/2.00.07. In the mean time, if you can use pulse audio as your output mode, that will work around the issue.

As for the no audio issue - this is likely to do with how you have configured your virtual machine instance. Alsa is unable to write to the output buffer. With virtual box running Linux, this is most likely due to not having the correct guest additions version installed.

Thank you. Note that I am using FMOD Studio v2.01.05 right now (you probably quoted one of the fixed version numbers wrong :smiley: )…

I know it works with Pulseaudio, but I happen to thoroughly hate Pulseaudio… :stuck_out_tongue:

And no, the VM is not badly configured for ALSA: the same viewer software, which may also be configured to use OpenAL instead of FMOD, works just fine and produces sound with OpenAL and ALSA as its backend…
The same viewer also works fine with FMOD + ALSA on all my bare metal Linux computers (tested on 4 different PCs, with different Linux distros).
It is however possible that a bug in the Virtualbox Linux extensions causes this issue (in the past I already encountered problems with sound under VirtualBox and ALSA as a backend on the host machine and with Windows VMs: an issue with audio buffer length).

Ah yes you are correct, I meant 2.00.15/2.01.07.

Yeah, so guest additions that I was referring to are the virtual box Linux extensions. With previous testing, we have found that the guest additions need to be reinstalled with the latest version after upgrading virtual box to avoid issues.