Stutters

[clemmyn23]

RE: kbz's comment

---

I think I found it. Need a bit more testing though.

So basically every time the tap sound plays the SoundPool code runs through the permission check in appOps to see if sound playback is allowed. And for whatever reason one of the checks throws an error (which happens quite often as evident in the stutters) it defaults to false (ie. yolo we'll play the sound anyway) while throwing an expensive error.

This is platform specific to Android since Sound.java implements AndroidSound which uses SoundPool.

Proposed solution: implement a custom play() method and check appops permission on app load.

Thoughts?

[kbz]

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?

[clemmyn23]

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!

[kbz]

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 :|