Per your request and per the sidenote in the last issue topic I created, it has been my observation that Mixere seems to have trouble with consistently looping tracks using a selected range in the position column.
Very easy to replicate, just load a sound file into any slot, select a range, set looping on, watch it stutter its way from the beginning or from the selected point over and over again.
I suspect this is in part due to some kind of breakage in Audiere's LoopPointSourcePtr class getPosition() code. I found in scanning what it was providing compared to the default Audiere source class equivalent function that it seems to be rather delayed in returning sample positions when testing Audiere for my GMALP project, and there's suggestions the previous developer knew of this in Mixere's Audio.cpp:
loop source position is 1 second in the future relative to sound
source position; we can partially fix it by rotating loop source
position backwards 1 second, but we'll still get bogus positions
when entering a loop for the first time.
My solution for this function's problematic behaviour in GMALP was rather than use the function at all, instead manually calculate where the sample position should've changed to given the track playback frequency, start/end positions, and the time between update calls (which may or may not apply in Mixere's case since GMALP was designed as a wrapper for Audiere calls to Game Maker, which has no asynchronous DLL call support per se). Even if this ends up being the way forward for Mixere though, I have to wonder why Audiere didn't just do that within the function in the first place.
Per your request and per the sidenote in the last issue topic I created, it has been my observation that Mixere seems to have trouble with consistently looping tracks using a selected range in the position column.
Very easy to replicate, just load a sound file into any slot, select a range, set looping on, watch it stutter its way from the beginning or from the selected point over and over again.
I suspect this is in part due to some kind of breakage in Audiere's LoopPointSourcePtr class
getPosition()code. I found in scanning what it was providing compared to the default Audiere source class equivalent function that it seems to be rather delayed in returning sample positions when testing Audiere for my GMALP project, and there's suggestions the previous developer knew of this in Mixere's Audio.cpp:My solution for this function's problematic behaviour in GMALP was rather than use the function at all, instead manually calculate where the sample position should've changed to given the track playback frequency, start/end positions, and the time between update calls (which may or may not apply in Mixere's case since GMALP was designed as a wrapper for Audiere calls to Game Maker, which has no asynchronous DLL call support per se). Even if this ends up being the way forward for Mixere though, I have to wonder why Audiere didn't just do that within the function in the first place.