Closed teamtwentythree closed 6 years ago
Yeah, it's probably about 16ms off since that's when you're calling AudioEngine.Update.
If you want you can try to incorporate AL looping into the Cue looping setup, but note that there's no real way to detect loopback, only buffer lengths. You'd have to base new variations on when, according to the Cue timer, the sound is likely to have looped, and then apply new variations, in addition to turning off loops at the right time and swapping out sounds if loops include randomized tracks.
This is definitely an accuracy issue, but I'll leave this up to you. My solution for this internally is to just write FACT, but that's a multi-month task and I imagine you'll want a fix sooner than that, and the one thing I've got that does looping in this way doesn't need this level of accuracy so I can't really put it in as a priority.
Yea, that makes sense to me. Should be able to find some solution on our end.
Closing as WONTFIX for the existing audio implementation, and FIXED in the FAudio rewrite coming up.
Note that even in Microsoft's XACT runtime there are still tiny gaps (and sometimes even overlaps) for variations on loop, FAudio just makes it act similarly to that.
So this is a fun bug. Based on my previous issue I noticed that when OpenAL does the looping, it plays properly. If the variation is detected and the looping is handled by FNA, it's slightly slower than OpenAL. Presumably due to the frame times. I think OpenAL is basically in line with XNA and the FNA looping is slower. Our repro was with a short sound effect, haven't tried longer ones. I'm guessing it's related to frame times and loosing a few ms from when the previous play ends, and our next play is detected and kicked off.
Repro: Short sound effect (<1s) with infinite looping (Variation not needed, looping handled by OpenAL) Short sound effect (<1s) with loop count set to 254 (Looping handled by FNA)