Sound delay on Android (again)

So the sound delay bug is back on Android, I believe ever since the OpenAL code (incl. ALc.c, etc) was bundled in with OpenFL. Whether or not I pre-cache a sound, running sound.play(); has a half second delay on any android device, and on any version I’ve tried.

A similar thing used to happen before:
https://muut.com/i/openfl/bugs:delay-on-android-sounds-wa

Sadly the fix I’ve used from the muut discussion no longer works :frowning: Anyone been able to figure out how to remove the delay? I am compiling with -Dlegacy, but I believe even that uses the OpenAL bundled code (as opposed to before, an openal.so file)

Any ideas?

I don’t think there’s an issue, whether OpenAL is statically linked or not, by linking it this way (in the same Lime build) we have eliminated a lot of the headache that used to affect trying to rebuild OpenAL for Android. It should be much simpler to change things like this.

Are you certain that when you changed that setting in the OpenAL code (project/lib/openal) that it was included in the rebuild (-Dlegacy), and that the newest version of your test application was installed?

I don’t know what the issue is caused by. I don’t think it matters that it’s linked this way either but something in the OpenAL code seems to force this slowdown.

To paragraph 2:, yes I did all those things. I made sure all the files were updated when I made any changes to ALc.c and others, even manually removed files and watched for new timestamps, and so on and so forth. It’s definitely something in that project/lib/openal code (and rather, for android, it has an openal-android folder as well, which I also tried to make modifications in)

I am at a loss for what the delay could be caused by. I’ve yet to run the openfl samples to test for the issue- which one would be a good test subject for sound effets? PiratePig?

PiratePig or PlayingSound, the latter is good for swapping the audio with your own file and testing it

the openal-android project should be the one used on Android, for both legacy or the newer code. You could try breaking it to be sure that your builds break, too :wink:

Honestly, OpenAL on Android has been pain – all Android audio has been a pain.

OpenAL-Soft has been updated to 1.16.0:

http://kcat.strangesoft.net/openal.html

It says “improvements to the OpenSL backend”, I wonder if the official version (instead of the fork) would work better?

Otherwise we could compare the branches on https://github.com/apportable/openal-soft with https://github.com/native-toolkit/openal-android (which we use right now)

Oh, one more thing when testing. There’s still the “music” vs “sound” difference in legacy, the newer code does not have a threaded “load as you go” playback method in yet, similar to the legacy “music” mode.