I am using the latest versions of OpenFL (8.9.5), Lime (7.6.3) and HaxeFlixel (4.6.3).
On iOS I noticed that sound effects play twice, with a fraction of second between them. This happens on both simulator and device. Strangely, when playing music, I can sometimes hear the first beat of the song playing twice, but after that it seems to play normally.
Sorry, I’m not sure what you mean by regression. It was working before with OpenFL 8.4.1, Lime 7.0.0 and HaxeFlixel 4.5.1. Haxe was also upgraded from 3.x to 4.
Also, what’s strange is that the problem doesn’t seem very consistent. Some sounds seem to play twice only sometimes, while with others I can’t really tell if it’s playing twice or not. I have another, simpler app that doesn’t seem to have the issue.
I checked if it could be due to a difference in audio format, but all of the files are ogg, 44100Hz, 32-bit.
I play it by simply calling FlxG.sound.play("assets/sounds/land.ogg") or FlxG.sound.play("assets/sounds/land.wav"). I did a simple test within the game to just play the sound when I tap, so I’m sure I wasn’t playing it twice in different parts of code.
Maybe you should try playing sounds thru OpenFL (not thru HaxeFlixel) to see if it’s the problem of the framework.
If not, try testing with older versions of OpenFL (<= 8.9.1).
I can reproduce the issue. On Android (may be other platforms).
If I preload sound with Starling AssetManager, when fps is lower than maximum, sound can be played twice. Works fine if sound is preloaded with OpenFL Assets class.
HTML5, Android, Chrome.
OpenFL 8.9.5, Lime 7.6.3
I have made some more tests, and can confirm that it does not seem related to flixel, since I played the sound by calling openfl.utils.Assets.getSound("assets/sounds/land.ogg").play();
Also, the problem does not occur with lime 7.0.0 and openfl 8.4.1, but it does occur with lime 7.1.0 and openfl 8.5.0.
The problem has not happened to me on Android, that I have noticed.
Had a similar problem. Openfl develop-v9 branch, html5 target.
I loaded sounds from remote server dynamically with starling AssetManager and they played twice. It looks like problem is in starling SoundFactory in creating sound from bytes:
Can you use the same OpenFL version with different Lime versions and see the issue occur/not occur? Does it occur with the most recent versions of Lime?
I can try that out soon, but it does occur with the most recent versions of Lime.
If I recall correctly, when I tested I kept trying an earlier version of lime, and only downgraded the openfl version when it was incompatible with lime. When I reached lime 7.0.0, and highest compatible openfl 8.4.1, is when the problem stopped.
I’ve tested with different sampling rates, mono and stereo, ogg and wav. None of these seem to make a difference.
The one thing I’ve noticed while doing further testing today is that it seems to only repeat the first 20ms or so of the sound file. Because of this, there are many sounds without the problem because they start in silence or very quiet, but with clicky menu sounds that start right away the problem is very apparent.
On the bright side, at least I can adjust those sounds to have 20ms of silence at the beginning, which fixes the problem for now
Before this change, I’m not sure if it was intentional or not, but lime was using mojoAL on iOS to play sounds. After this change, lime started using the OpenAL framework included in Xcode, I guess.
Playing sounds with MojoAL (according to the person I asked to test it) resulted in poor-quality sounds. I’m not sure what the issue was, but I decided to take a closer look at what was going on with the OpenAL framework version first to see if it couldn’t be properly fixed.
I found what appears to be the issue, so I’ll make a PR later. I suppose the iOS OpenAL implementation handles setting BYTE_OFFSET a little differently from openal-soft. Perhaps there’s a queue of sorts, or messages are passed slowly because of some detail related to how the threading works? Who knows!
I have simmilar problem for html5 target
I manually update howler.min.js to ver.2.2.4 (\HaxeToolkit\haxe\lib\lime\8,0,2\dependencies). It helps me.
Seems it is good idea to update dependencies with next lime release.