Audio does not pan when using MojoAL

[zanzlanz]

Version

Lime 7.9.0, Haxe 4.2.3, Windows 10.

Problem

When static building Lime, audio does not respect the position value for panning. When building without static linking, panning behaves as expected. The main file I've been testing with is a mono-channel .OGG.

This difference is due to Lime using MojoAL instead of OpenAL to play audio on static builds (for licensing reasons).

Maybe the pan binding differs between these two libraries?

Workaround

I'm not aware of a proper workaround without making non-static builds. Stereo files play fine, but panning has no effect (OpenAL behaves that way too; it's a known limitation).

Example Project

Here's a small sample project for replicating, including a test.ogg. Run with lime test cpp -static to replicate the issue. Run with lime test cpp to hear the intended panning. LimeAudioPanTest.zip

Code

package;

class Main extends lime.app.Application {
    override function onPreloadComplete():Void {
        var buffer = lime.utils.Assets.getAudioBuffer("assets/test.ogg");
        play(buffer, 1, -1); // Pan left at 1s
        play(buffer, 2, 0);  // Pan center at 2s
        play(buffer, 3, 1);  // Pan right at 3s
    }

    function play(buffer:lime.media.AudioBuffer, delayInSeconds:Float, pan:Float):Void {
        haxe.Timer.delay(function() {
            var source = new lime.media.AudioSource(buffer);
            source.position = new lime.math.Vector4(pan, 0, -Math.sqrt(1 - Math.pow (pan, 2)), 0);
            source.play();
        }, Std.int(delayInSeconds*1000));
    }
}

[player-03]

Can you test this with #1531 and see if the update helps?

[zanzlanz]

@player-03 Unfortunately the project above is unable to build using your branch without errors.

When building statically I get: LINK : fatal error LNK1181: cannot open input file '(my dev directory)\lime\ndll\Windows64\liblime-19.lib'

When building non-statically, I get this error much earlier in the pipeline: Uncaught exception - load.c(237) : Failed to load library : lime.ndll

[player-03]

Oh right, you might need to run git submodule update, lime rebuild tools, and lime rebuild windows -clean. I keep forgetting to mention all the steps...

[zanzlanz]

Hm I think lime automatically rebuilt after switching to your PR, and I did recurse submodules when pulling. But I ran those commands anyway:

git submodule update has a "SSL certificate problem" for libpng and tinyfiledialogs; they're both hosted on git.code.sf.net.

and the lime rebuild commands both show these errors (only tools encounters the ValuePointer one):

Error: ValuePointer.cpp
include\system/CFFI.h(6): fatal error C1083: Cannot open include file: 'hl.h': No such file or directory

Error: TextEvent.cpp
include\system/CFFI.h(6): fatal error C1083: Cannot open include file: 'hl.h': No such file or directory

Error: CairoBindings.cpp
./src/graphics/cairo/CairoBindings.cpp(1): fatal error C1083: Cannot open include file: 'cairo.h': No such file or directory

[joshtynjala]

It might be worth trying git submodule update --recursive.

SSL certificate problem

I suspect that you won't be able to rebuild until you resolve this error first.

[zanzlanz]

I gave it another shot now that I see the submodule branch is merged into 8.2.0! I used git submodule update remote --recursive and it seems to have pulled everything in without the issue like before.

The errors I'm getting now when running lime rebuild windows -clean changed slightly:

Error: GamepadEvent.cpp
include\system/CFFI.h(6): fatal error C1083: Cannot open include file: 'hl.h': No such file or directory

Error: WAV.cpp
include\system/CFFI.h(6): fatal error C1083: Cannot open include file: 'hl.h': No such file or directory

I'm up to date on the 8.20-Dev branch, and have the latest stable of Haxe installed. Do you have any suggestions what I should try next?

[player-03]

No idea, but check in project/lib/hashlink/src to make sure the file actually exists. Assuming it does, next add some <echo /> tags to Build.xml to make sure it's being included correctly.

        <compilerflag value="-I${NATIVE_TOOLKIT_PATH}/hashlink/src" />
+       <echo value="-I${NATIVE_TOOLKIT_PATH}/hashlink/src" />
+       <echo value="${LIME_HASHLINK}" />

Beyond that, I don't know.

[zanzlanz]

(Thanks again for the help over on Discord! My submodules were remembering the wrong repo URLs.)

Can you test this with #1531 and see if the update helps?

I ran lime rebuild windows -static -clean, re-downloaded my example project above, and gave it another shot. Unfortunately, no success. When making a static build with embedded assets, panning still does not work, and there is an audible clicking sound at the end of the audio.

I believe this is my only blocker for being able to statically link the ndll (which would be so great for end users).

Strange that MojoAL would be doing this as a drop-in replacement. Do embedded assets go through any additional processing that MojoAL would handle differently than OpenAL?

[player-03]

Unfortunately, I've never used* and have no experience debugging MojoAL, sound panning, embedded assets, or static builds. Sorry.

*I haven't directly used, anyway. I'm sure Lime has used MojoAL under the hood, but I wasn't doing anything fancy with it, so it worked fine.