3

When I play a sound in my app it comes off as clippy and distorted. Here is a recording: recording.

Here is the sound file as it was uploaded to android studio: success sound cue

Here is the function that calls the sound from the .raw

 public void playCorrectAnswerSound() {
        final MediaPlayer mp = MediaPlayer.create(this, R.raw.correct);
        mp.start();
    }

Heres how I call it:

Thread t = new Thread(){
            public void run(){
                playCorrectAnswerSound();
            }
        };
        t.start()

This is my first time debugging a sound related issue. I don't know what else to include in this post, so if you need more info please say so.

EDIT: I was asked to record more of the distortion. Here it is. Also I should say that after more testing, my physical device lacks the sound distortion while the sound distortion is present on 3 different emulators.

Fletcher
  • 621
  • 6
  • 16
  • Yes my too is like it. It fades! – Gourav Jan 04 '19 at 15:16
  • This is interesting. I'm leaning towards "MediaPlayer buffer starvation" due to your device doing too much work while the sound is playing. If you could upload another 2-3 recordings of the bad audio, I will take a look at them (it is hard for me to prove my buffer starvation theory with just one recording). Maybe check logcat for any mediaplayer-related messages, too. – greeble31 Jan 04 '19 at 18:44
  • @greeble31 just record it again 3 times? About the logcat - how do mediaplayer related messdages look like? – Fletcher Jan 04 '19 at 19:07
  • 1
    1.) Yes, I just want to hear it a 3 more times. It can be one recording, just play the sound 3 times. 2.) I'm not sure; just filter on "mediaplayer". – greeble31 Jan 04 '19 at 19:35
  • @greeble31 added the recording with more info – Fletcher Jan 05 '19 at 16:18
  • I looked at that clip in Audacity and it does confirm that the distortion (which consists entirely of unexpected clicks) is random, from play to play, except that it always seems to happen at some multiple of a 13ms interval. That, and the fact it doesn't happen on a hardware device, is all suggestive of buffer starvation. Are your emulators underpowered? Is your app doing a lot of work at the time these sounds are playing? – greeble31 Jan 05 '19 at 17:04
  • @greeble31 the app doesnt run any async tasks and nothing is multithreaded. These are topics iv'e yet to tackle. I've also failed to find good articles online about buffer starvation. Any good resources? – Fletcher Jan 05 '19 at 17:06
  • 1
    I would look at [this question](https://stackoverflow.com/questions/5343730/mediaplayer-stutters-at-start-of-mp3-playback), and also [this answer](https://stackoverflow.com/a/15455675/6759241) (which suggests a technique that might work). Could just be your emulators are simply too slow, so you wouldn't have to worry about it in production. You could test your .mp3 using the emulator's media player app, for added confidence. – greeble31 Jan 05 '19 at 17:20
  • 1
    About the multithreaded thing - I believe that your app probably isn't overworked, but clearly, based on the code you've posted, it is multithreaded. Which is actually a bit strange for this use case. The standard way is to make the MediaPlayer a member variable, `create()` it during app startup, and `release()` it once you're all done. You've got it as a local variable in a `Thread.run()`. Or, better yet, use SoundPool, which is a bit better suited to handling short sounds like this. – greeble31 Jan 05 '19 at 17:22

1 Answers1

3

I'm going to say this is stuttering due to underrun (starvation) of the MediaPlayer's internal playback buffer. That is, the MediaPlayer can't supply data fast enough to keep up with the sound hardware (which suggests a severe lack of processing power). If the buffer starves, it'll start to play back old data (because it's a circular buffer). This causes a sharp phase transition, which sounds like a "click". Presumably the MediaPlayer recovers quickly enough that the "correct" sound resumes playing shortly thereafter.

Here is a picture of the spectrum from Audacity. 0-4KHz. The first row is the clean .mp3; the next four rows are the distorted recordings (in no particular order). All rows have been aligned in time, and are roughly the same amplitude. The large vertical stripes in the last four rows represent the distortion/clicks that you hear.

5 rows of sound spectrum - Audacity screenshot

greeble31
  • 4,894
  • 2
  • 16
  • 30