No sound in videos, but ingame all sounds/music works fine. v2.0.104.737. ALSA, no pulseaudio.

Terminal output:

ALSA lib pcm_dmix.c:1024:(snd_pcm_dmix_open) unable to open slave
AL lib: (EE) alsa_open_playback: Could not open playback device 'default': Device or resource busy
ALSA lib pcm_dmix.c:1024:(snd_pcm_dmix_open) unable to open slave
AL lib: (EE) alsa_open_playback: Could not open playback device 'default': Device or resource busy
ALSA lib pcm_dmix.c:1024:(snd_pcm_dmix_open) unable to open slave
AL lib: (EE) alsa_open_playback: Could not open playback device 'default': Device or resource busy
ALSA lib pcm_dmix.c:1024:(snd_pcm_dmix_open) unable to open slave
AL lib: (EE) alsa_open_playback: Could not open playback device 'default': Device or resource busy

I'll check on that.
What are your system specs?

Debian Testing x64, ASUS P8Z77-V LE PLUS, i5-3570K CPU @ 3.40GHz, GTX 650 Ti BOOST, ALC889 Realtek integrated soundcard.

After updating alsa terminal output there is one new line in terminal output:

AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
ALSA lib pcm_dmix.c:1029:(snd_pcm_dmix_open) unable to open slave
AL lib: (EE) alsa_open_playback: Could not open playback device 'default': Device or resource busy
ALSA lib pcm_dmix.c:1029:(snd_pcm_dmix_open) unable to open slave
AL lib: (EE) alsa_open_playback: Could not open playback device 'default': Device or resource busy
ALSA lib pcm_dmix.c:1029:(snd_pcm_dmix_open) unable to open slave
AL lib: (EE) alsa_open_playback: Could not open playback device 'default': Device or resource busy
ALSA lib pcm_dmix.c:1029:(snd_pcm_dmix_open) unable to open slave
AL lib: (EE) alsa_open_playback: Could not open playback device 'default': Device or resource busy


Also, game crashes on quit:

Thread "EoCApp" (4180469504)
received signal 11

Call stack:

(0) /lib/x86_64-linux-gnu/libc.so.6 : +0x33590 [0x7fbc0995c590]
(1) /lib/x86_64-linux-gnu/libpthread.so.0 : pthread_mutex_lock+0x4 [0x7fbc09cd6824]
(2) ./EoCApp : AK::MemoryMgr::Malign(int, unsigned long, unsigned int)+0x3d [0xfd356d]
(3) ./EoCApp() [0x10d353d]
(4) ./EoCApp() [0x10eeaf3]
(5) ./EoCApp() [0x10ba2bb]
(6) ./EoCApp() [0x10ba9f2]
(7) ./EoCApp() [0x10bab16]
(8) ./EoCApp() [0x10ce8b5]
(9) ./EoCApp() [0x1073040]
(10) ./EoCApp() [0x10b6421]
(11) /lib/x86_64-linux-gnu/libpthread.so.0 : +0x7284 [0x7fbc09cd4284]
(12) /lib/x86_64-linux-gnu/libc.so.6 : clone+0x6d [0x7fbc09a1197d]

Hi, I know this is an old thread, but I am experiencing the exact same issue with D:OS EE in Linux, where I get no sound in the videos, but it's fine everywhere else (e.g. menus, in-game). I also get the exact same error message about ALSA failing to initialize the Pulse backend.

Like the OP, I am also using ALSA direct with no Pulseaudio, so it seems that might be the common denominator? Perhaps for some reason the videos are reliant on Pulseaudio, but the audio elsewhere isn't? I will poke around and try a couple of things.

(the game is awesome, btw. I'm really enjoying it! :-) )

Hey, thanks for your reply. I'll give that a try and let you know if it helps :-)

fuser shows that the only other processes using the sound devices are related to the desktop environment (i.e. mate-settings-daemon). So, I'm not sure I want to be killing those. I tried it in LXDE as well as Mate and I get the same audio issue.

I don't seem to have any /etc/asound.conf or ~/.asoundrc files.

I also tried installing the apulse package, which apparently should allow apps to use ALSA that are only configured to use Pulseaudio; however, that also didn't seem to help.

The idea is to see what process, if any, is interfering. If you find that it works without the processes running, ,you may be able to work around it, possibly using an asound.conf/.asoundrc. I'd post (or upload somewhere) my /etc/asound.conf, but it's complex, painful, and doesn't work right all of the time, either. Probably the key is to have an explicit dmix instead of relying on the default.

The fact is, ALSA is extremely poorly documented, barely functional crap (that I recently found also has devs with bad attitudes). That's why pulseaudio was born to begin with, I assume. It's probably also why "professional" sound packages tend to not work correctly (in particular FMOD). I felt that ALSA should've gotten the paid attention instead, so I still use ALSA. I'm probably not going to keep doing that for much longer, unless I rewrite libalsa to work around some of these stupid issues.

So, my recommendation to you is: switch to pulseaudio. Much like apulse, pulseaudio has a wrapper which makes ALSA apps use pa instead.

I don't have any other apps open that are using audio. The only other thing that seems to be accessing those device files is the desktop environment, and that seems to be just for the purpose of controlling overall volume (through the panel widgets).

As far as ALSA not being very good: in my experience, I have found it seems to work well. My sound card appears to be able to multiplex well by itself. If I have multiple apps playing audio (e.g. a game and rhythmbox), the sound blends fine and I can adjust the volumes in the individual apps. So, it is literally just the audio in the videos for this game that I am having a problem with. I agree that ALSA is not well documented though, especially in terms of the general configuration and how to troubleshoot if something isn't working.

I'm not a fan of pulseaudio. I was using it before but had some other issues relating to it. In particular, I like to use firejail to sandbox certain apps (including some games - I am running D:OS EE in firejail). Firejail seems to be totally incompatible with pulseaudio, but seems to work fine with just ALSA.

It's not a huge deal. If I can't get it working, I'll just carry on without audio in the videos. The videos seems fairly infrequent and the game is otherwise pretty awesome :-)

I had wondered if it was an SDL settings thing (assuming the videos are using SDL and the rest of the game OpenGL). E.g. SDL is trying to use Pulse for audio. Is there a more detailed config file anywhere for the game?

I decided to play with it on my system a bit, in spite of my bitter disposition and limited resources. I now have a guess as to what might be the problem, and what you can do to fix it.

Try doing the opposite of what I suggested: instead of killing audio apps, find a way to lock the hardware PCM device. Try playing a sound in the background for long enough for the game to start up. That is my suggested workaround. I have not tested it, because I ran out of time (and am currently on battery power again, so I can't test it until later).

Here's why: the one thing, of many things I tried, which caused this problem for me was killing timidity. I normally run timidity on system startup to provide MIDI emulation on demand. The process locks the hardware PCM (indirectly, by properly opening the default device, which uses dmix). Most games/programs that can't be bothered to use ALSA correctly fail due to this, but this game actually does the opposite. I suspect the game opens the first device it can for the game, and then, later, opens the first device it can (separately) for movies. If it fails to open the exclusive hardware device, it'll fall back to the shared dmix. If it succeeds in opening the exclusive hardware device, even the same process can't open another sound device (for movies).

If the game only opens audio once, playing a sound (on the dmix device, such as "default") at startup will be sufficient: both he game and movies will end up using dmx-enabled default from then on. Otherwise, it might be necessary to play a sound for the entire game. One way to do this would be to play /dev/zero as raw audio at a slow enough frequency to not impact the CPU. Try looking for a way to get aplay to do this, I guess.

Again, this is only a guess. At worst, you could try running timidity as well, but I'm sure there's nothing special about it. If I think about it again later, when I am able to test, I will test, and report back tomorrow. Either that, or I'll just play another game and forget about it.

Hey darktjm, I think you were right. I opened Rhythmbox and started a random radio station; turned the volume way down so I couldn't hear it. Then, when I started the game, the sound in the videos worked. If I do the reverse: start up the game first, then try to play a station in Rhythmbox, I get no audio in the in-game videos and I also get nothing from the radio.

So, as you suggested, it seems if I start the game with nothing else using audio then it grabs some exclusive ALSA mode, which locks out its own videos, as well as other apps. Interesting!

Thanks very much for your help in resolving this! From now on, I will keep a radio station running on v low volume as I play the game :-)

Actually, it might be better to add the following line in your startup script:

aplay -q -d 5 /dev/zero & sleep 1

or, if you want to be explicit:

aplay -q -D plug:default -d 5 /dev/zerio & sleep 1

This plays 5 seconds of silence, probably long enough for the logo video to start, by which time the game will have initialized its audio. The sleep is to ensure that the aplay starts before the game. Doing this is enough for me to get audio in the logo and new game videos, so I don't think the game closes and reopens the audio during gameplay. If you end up finding that it does, you can still script it to play silence for the entire game:

aplay -q /dev/zero & pid=$!; sleep 1
..
# run game (EocApp)
..
kill -2 $pid

Assuming you have aplay (alsa-utils) installed, of course. And, if you are using ALSA, you probably should if you don't.

I still stand by my suggestion to switch to pulseaudio. It will probably save headaches in the long term. I don't like or use filrejail myself: I am not that paranoid, and firejail just does too much and is not easy to use. Instead, I deny all games and wine programs 'net access, using a disconnected network namespace (one-time setup) and a modification of iproute2 that just runs stuff in that namespace. The source and documentation for how I do this is at my misc game support project.

Thanks for your suggestion and sorry for the delayed reply. I tried that startup script and it works really well.

I will take a look at some of the other scripts you have at the link you provided too. Those look very interesting!