I was testing the Audition app made by @matt, which allows you to play audio files and view images on the device. I noticed that as I added more songs, eventually they would start randomly skipping to the next song. Looking at the code for Audition, it seems that the finishCallback set by fileplayer:setFinishCallback() is called early when there is a performance hitch caused by low fps or garbage collection. This issue can be alleviated by increasing the buffer size when creating the fileplayer, so it seems that the buffer size is directly related to this issue. This issue only happens on device, as the simulator runs too quickly to create these performance hitches.
Here is a pdx file with some sample files included. There are two music files (PDA, compressed IMA ADPCM), and a bunch of test images to create a load on the system. If you play the first music file, you will notice that it randomly skips to the next song. Then shortly after that, the second song will also stop. Scrolling up and down the file list while a song is playing seems to make it happen faster.
I have found another potential bug related to performance hitches. It seems like the ButtonDown and ButtonUp callbacks may be skipped if there is a lag spike. In the Audition app, it sets a keyRepeatTimer on button down, and then removes the timer on button up. However, sometimes the button up callback is skipped, causing the timer to just run endlessly as if the button was stuck. In the example pdx, you can trigger this by pressing (not holding) up or down very quickly in succession. You can prevent this in code by using if keyTimer then keyTimer:remove() end right before you create a new timer.
I tried setting the app to 50 fps, but it will only run up to 30. The problem still happens with the missing button presses at 30 fps. It specifically seems to happens when there is a large garbage spike, which apparently listViews are very good at creating. The buffer underrun problem also happens, but it seems like it happens less often.