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 -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.
I get the same results.
The ratio between the position I get and the one I asked is constant:
soundChannel = sound.play( 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?
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”.
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
