OpenAL errors in Windows

I’m using HaxeFlixel in Windows, and keep getting the following error when I try to play a sound in my game…

AL lib: (EE) MMDevApiOpenPlayback: Device init failed: 0x80004005

The exact same code works fine in Android and on my Windows 7 laptop, however on my Windows 7 desktop it randomly (and more frequently than not) crashes the game with the above error.

Since HaxeFlixel doesn’t directly deal with OpenAL, it’s been suggested I raise this problem over here.

A bit of Googling doesn’t turn up much apart from a few people hinting at maybe it relates to trying to open an audio device that isn’t configured correctly or not active. My PC has an onboard sound device and then also one built into the HDMI output of the graphics card.

Sound is working fine on my PC in all other programs.

Can anyone help?

Would you mind setting up a small project (preferably without Flixel) that just tries to play a sound. See if it works normally, but also see if it works using “-Dnext”

Knowing if it fails in both or not, would be helpful. Also, if you can run it with “next” defined, then it would also allow us to use Lime’s OpenAL bindings, which could give us more details about which device it is trying to use, and what we can use to find a fix.

I created a simple OpenFL project by using

lime create openfl:project MyProject

Then, in Main.hx I put this, and put a random Wav into the Assets folder.


import openfl.display.Sprite;
import openfl.Assets;

class Main extends Sprite {

        private var sound:Sound;
        private var channel:SoundChannel;

        public function new () {
                super ();

                trace ("Hello");
                sound = Assets.getSound("assets/sound.wav");

                trace ("There");
                channel =;

                trace ("Played");

Compiling it with

lime test android

Makes the sound play OK on my OUYA. Trying

lime test windows

Causes a window to appear, but windows labels it “Not responding” and prompts me to kill it off. On the console the

Main.hx:26: Hello

trace() is printed, so it crashes when doing Assets.getSound(). The same happens when using

lime test windows -Dnext

I had (fun!) using some trace() debugging to try and find out where the crash was happening. I managed to get as far as

__handle = lime_sound_from_file (stream.url, forcePlayAsMusic);

in openfl/_v2/media/Sound.hx (around line 96) but couldn’t go any further since that’s just a call into the lime dll. This is OpenFL 2.1.1

I can’t remember/figure out how to make the OpenAL errors appear again. I tried wrapping stuff in try/catch blocks but there weren’t any errors caught.

In “next” it uses bindings to OpenAL, that may be much simpler to debug. It maps back to and, generally. So we actually have an ability in the new Lime to ask OpenAL what devices it sees, to control how it initializes, etc, all without leaving Haxe, which should be a lot simpler to play with than delving into C++ stuff :slight_smile:

Sorry to bump such an old post, but I’m having a problem with OpenAL errors when playing sounds targeting c++. On Android the sounds cut out at times (at least on my old phone). I’m sure these errors are due to my older, low-memory devices, but I’d like to fix it to work with them, if possible.

I get these OpenAL errors:

  1. OpenAL error was raised: 40961 (File not found or supported)
  2. OpenAL error was raised: 40965 (Out of memory)

Some specs and notes:

  1. Old laptop with win7, 4GB RAM.
  2. I only notice when using my 2nd HDMI connected monitor. Error doesn’t happen at all if I move app to the laptop screen.
  3. Doesn’t seem to be a problem unless running full screen.
  4. I am playing many sounds at any given time.
  5. This is a flixel game and I’ve tried with old and new versions resulting in the same errors.

Setup 1:
flixel: 4.3.0
lime: 2.9.1
openfl: 3.6.1

Setup 2:
flixel: 4.4.2
lime: 6.4.0
openfl: 8.3.0

Is there anything I can do to prevent this? Any advice?

Is there a difference between Setup 1 and Setup 2 in regards to how it works?

We added “MojoAL” support recently, which uses SDL for audio under the hood, instead of OpenAL-Soft, so there’s a chance that might resolve some issues (without changing any other code)

Seems to work the same with both, although it wasn’t a problem before with setup 1. I’m looking at some recent changes I’ve made and probably it’s my code.