SoundChannel::position accuracy

When playing a sound, it seems as though SoundChannel::position is only updated every 185ms or so:


Instead of something more frequent, like this:


It also seems that there is a roughly 371ms “skip” in the position when playing a sound. For instance:

channel =;
trace(channel.position); // 371.519274376417ms instead of 0ms

channel =;
trace(channel.position); // 10371.5192743764ms instead of 10000ms

Tried this with multiple OGG files on Windows.

Anyway to remedy this?

This may be something with either libogg, OpenAL or the thread we use to update it. A couple things that might help to identify the cause:

1.) Could you try the difference between embedding as <assets path="to/sound.ogg" type="music" /> and <assets path="to/sound.ogg" type="sound" />

2.) If it’s not difficult, could you try testing just the sound using a small sample in both native (like neko or mac or whatever) and also trying the same using the -Dnext flag to compare against the newer codebase as well

Using type="sound" did the trick! It even properly starts at 0.


Tested with windows and neko.

Using -Dnext flag, I actually get nothing but 0’s for both windows and neko. Did a haxelib upgrade before testing, so everything should be up to date.

Edit: Though, it seems if I start on something other than 0, the “skipping” thing occurs again, and the higher the starting number, the higher the skip is.

0     => 0
100   => 101.655326783657
10000 => 10167.3011779785
50000 => 50836.5745544434

Ok, it’s weird.

I get the same results.
The ratio between the position I get and the one I asked is constant:

soundChannel = position );
trace( position, soundChannel.position, soundChannel.position / position );

For a same file, even if they have exactly the same encoding, the ratio is constant and a bit higher than 1.
But it vary from one file to another.

This ratio is small, but big enough to mess things up on long ogg files.

I tried on both windows and Android.
The value seems to be constant between the 2 platforms ( meaning that for playing the same file, I will get the same ratio on both platforms ).
This means I could hard code this ratio… obviously that’s a last resort and I’d like a better solution.

I’m not sure I’m up to date on all my libs:
lime 2.0.0
openfl 2.1.6
But I am at the very end of my projects, and I don’t want to introduce new bugs… so I’d like to know if this has been fixed?

Anybody has a fix for this?

No, not yet, has this been reported On Github?

It wasn’t, I opened one:

A bit more than two weeks and still nobody assigned on the bug.
I guess I’m gonna fix it with a workaround ( hard-write a ratio for each file ).

Now don’t get me wrong, I know what is OpenFl in therm of man power, and I don’t expect miracles.
But I can objectively say that it is what makes me hesitate whenever I start a new project.
“What if I find a bug without a workaround”.

Hey @Horsetopus

I’m not exactly sure what is going on here, I know that some audio formats don’t put “frames” anywhere except under certain intervals, it could be related. Another possibility is that the values are off by a buffer size – like it’s read farther than what it is currently playing, because it is buffered. It’s a couple ideas. I don’t think the types of problems we’ll have will be “big and scary” in general, I think this becomes more manageable over time.

I had some API changes held up in Lime 2.1 that was just released, I think there may be another “bug sweep” coming up that may be able to visit this again and see if I can find what’s really going on

The GitHub issue above isn’t the original problem in this thread, so I opened another: