Stutters about siftrain HOT 3 OPEN

Does this happen only when there's simultaneous taps? Or does it happen on normal hits as well? A work-around would be to add some kind of sound handler and add cool-downs to sounds so that they can't happen at the same time. Or maybe the 'solution' would be removing the hint sounds? I still believe that even without sounds at all (Only the mp3 sound file) there's lag spikes / stutter. Any thoughts on this?

from siftrain.

Apologies about the late reply. Been a busy week.

Ran some more tests..

• Don't think the try block above in SoundPool.isRestricted() is the main cause of stutters since it's consistently throwing exceptions every time (<3ms).
• "Lag spikes" that occur without tap and hint sounds enabled never exceeded 1ms during my test runs.
• Not related to sync since stutters are present even though I have sync disabled.
• Stutters seem to occur consistently at specific parts of some songs. This is interesting.
• Tried adding 'flags' to implement the cool-down thing you mentioned but it doesn't seem to help much (still lag spikes/stutter)
• Does not have anything to do with new accuracy markers and popup obj creations at WorldController.hit()

So yea.. Quite sure it's something to do with sound.

Might see if running tap sounds on a different thread helps as a temporary workaround (won't eliminate audio issues but it's better than having >100ms stutters on the gui thread). Kinda want to solve this before having to dig into Android libs and sacrifice all the libgdx portability. Worst case scenario I'm happy to poke around Android AudioTrack and writing tap sounds directly into the audio buffer, but would like to make sure this stutter isn't something to do with the current codebase.

Looks like there are some interesting threads over at libgdx forums. Research time!

Android audio why is this such a pita? Why can LLSIF do this properly and we can't :/

Throughs, comments and suggestions on what else to test would be awesome!

from siftrain.

Another way may be playing the song from a separate thread (as well as the tap sounds) so that the GUI is partially isolated from the backend. Have you tried checking how long the 'getCurrentPosition' method call on the song takes? Maybe that's what's slowing down on "heavy" sections of the song. I can't say for sure and I don't have a test device anymore :|

from siftrain.