Can too many audio channels cause stuttering graphics on some Android devices?

Audio and Graphics
#1

Hi all,

I’ve been developing a 2d scrolling game and on iOS performance is sublime.

However on my Android device (Samsung GT running Android 4.2.2) it appears frame rates are slowing intermittently leaving the game feeling jerky / jumpy.  It’s nowhere near as smooth as on iOS.  So the game on Android is not really playable.

I’ve been reading a lot of forums regarding Android performance and one that raised my eyebrows was that too many audio channels can affect performance.

I was on the train playing my game on the Android device but with earphones and suddenly the game was scrolling as smoothly as my iOS device.  I unplug my earphones and hear the game through the speakers of the device and performance degrades - the scrolling is jerky and jumpy.  I plug in my earphones again and the game is smooth again.

Has anybody encountered this?  Is it a limitation on the speakers on my device?  Is it because I have too many channels.  I am utilizing 32 channels in my game.

Any info would be great and thanks for reading.

#2

Well 32 sounds going at once could use a lot of memory and a good chunk of CPU time to process, in particular if these are stereo, high bitrate sounds.

There really isn’t much for us to go on other than generalities.

Rob

#3

Thanks for the reply Rob.

To test, I commented out ALL sound code and performed the same test.

With earplugs plugged in using the Samsung GT, animation is very smooth and as expected.

Without earplugs it’s jerky and fps fluctuates.  I performed these two tests about 20 times.

So it appears it’s nothing to do with sound at all but the speaker of the device even though there is no sound at all.  Is this even possible?  I know, it’s a weird situation!

#4

This is very bizarre.  The app is still liking to the device’s OpenAL code and perhaps your android setup (Version, device + carrier code) might be causing an issue just because the OpenAL code is initialized.  I’m asking engineering for their thoughts on this, but I suspect its not a common issue that’s going to be.

Rob

#5

Can you try building a sample app like FrameAnimation that does not use audio at all and see if your headphone / speaker test impacts performance?

#6

G’day Rob,

I ran FrameAnimation1 as you suggested (at 60 fps since it’s easier to see a smooth animation) and the apple moved smoothly without any stuttering.  It was smooth without headphones and with headphones.  All good.

Then I added one line of code (and made sure the sound file existed)

local laserSound = audio.loadSound(‘laserSound.mp3’);

And ran FrameAnimation1 again WITHOUT playing the sound.  Just declaring / making use of the the ‘audio’ package.

This time, without headphones after about 1 to 2 seconds the apple animation is jerky / stuttering.  It’s smooth for a second, and then it stutters.  And as soon as I plugin in my headphones, the apple movement is consistently smooth.

Just to be sure, I commented out the audio line above and ran the test and the apple animates smoothly without stuttering with or without headphones.

I must have performed this test about 20 times just to make sure.  To a gamers eye, it’s definitely there.

So it appears simply referencing the audio package causes stuttering without headphones on my Samsung GK device.

I’m at a loss.  I don’t know what Android devices you have available at your disposal.  I wish I had more.  Any chance you / engineering could perform the same test and let me know the results?  Maybe it’s just my device which has a faulty external speaker although I purchased it brand new last week.

But it’s killing me as my iOS version is ready for release and I’d love to have the Android version available at the same time.

Thanks for your time once again.

#7

I did you you said, 60 fps, created on version of Frameanimation1 that loaded a .wav (didn’t have a small .mp3 handy) file and one that did not.  Installed them both on my 1st Gen Google Nexus 7 tablet running 4.4.

There is no difference in playback regardless of the loading or not loading of the audio, nor is there a difference with headphones plugged in or not.

Audio, just the act of loading it will cause the device to load certain audio libraries, and codecs (coder/decoders) for processing the audio.  Loading it causes it to go through the Audio decoder and that will put stress on the CPU.  For devices with single core systems, depending on the quality of the GPU, this could put a heavier  workload on the CPU.  Many Android phone makers are trying to build systems that cost less to produce and will introduce lower power versions.  Samsung is notorious for doing this with their GPUs.  Almost every phone they have there is a premium GPU version and an intro GPU version.

If you are still loading a bunch of sounds, they very well could be taxing the CPU. You might want to consider several options:

  1. preload the sounds that get used frequently, in particular at times when the things are slow (like showing  a menu).

  2. Make sure to use 11khz, mono sounds.  They take up less memory, take less time to decode and are easier to play back, in particular for sounds that play frequently. 

  3. Try a different audio format.  Sometimes the codec’s installed are not necessarily from Google and some maybe easier to digest on some devices.

There are so many different android devices made by a bunch of different companies who contract other makers to build the parts and then they fork a version of Android for their device, customize it, then let the carriers (Verizon, AT&T etc.) to add in their own drivers and such.  It makes for a tough mess to build and support for.

Rob

#8

Well 32 sounds going at once could use a lot of memory and a good chunk of CPU time to process, in particular if these are stereo, high bitrate sounds.

There really isn’t much for us to go on other than generalities.

Rob

#9

Thanks for the reply Rob.

To test, I commented out ALL sound code and performed the same test.

With earplugs plugged in using the Samsung GT, animation is very smooth and as expected.

Without earplugs it’s jerky and fps fluctuates.  I performed these two tests about 20 times.

So it appears it’s nothing to do with sound at all but the speaker of the device even though there is no sound at all.  Is this even possible?  I know, it’s a weird situation!

#10

This is very bizarre.  The app is still liking to the device’s OpenAL code and perhaps your android setup (Version, device + carrier code) might be causing an issue just because the OpenAL code is initialized.  I’m asking engineering for their thoughts on this, but I suspect its not a common issue that’s going to be.

Rob

#11

Can you try building a sample app like FrameAnimation that does not use audio at all and see if your headphone / speaker test impacts performance?

#12

G’day Rob,

I ran FrameAnimation1 as you suggested (at 60 fps since it’s easier to see a smooth animation) and the apple moved smoothly without any stuttering.  It was smooth without headphones and with headphones.  All good.

Then I added one line of code (and made sure the sound file existed)

local laserSound = audio.loadSound(‘laserSound.mp3’);

And ran FrameAnimation1 again WITHOUT playing the sound.  Just declaring / making use of the the ‘audio’ package.

This time, without headphones after about 1 to 2 seconds the apple animation is jerky / stuttering.  It’s smooth for a second, and then it stutters.  And as soon as I plugin in my headphones, the apple movement is consistently smooth.

Just to be sure, I commented out the audio line above and ran the test and the apple animates smoothly without stuttering with or without headphones.

I must have performed this test about 20 times just to make sure.  To a gamers eye, it’s definitely there.

So it appears simply referencing the audio package causes stuttering without headphones on my Samsung GK device.

I’m at a loss.  I don’t know what Android devices you have available at your disposal.  I wish I had more.  Any chance you / engineering could perform the same test and let me know the results?  Maybe it’s just my device which has a faulty external speaker although I purchased it brand new last week.

But it’s killing me as my iOS version is ready for release and I’d love to have the Android version available at the same time.

Thanks for your time once again.

#13

I did you you said, 60 fps, created on version of Frameanimation1 that loaded a .wav (didn’t have a small .mp3 handy) file and one that did not.  Installed them both on my 1st Gen Google Nexus 7 tablet running 4.4.

There is no difference in playback regardless of the loading or not loading of the audio, nor is there a difference with headphones plugged in or not.

Audio, just the act of loading it will cause the device to load certain audio libraries, and codecs (coder/decoders) for processing the audio.  Loading it causes it to go through the Audio decoder and that will put stress on the CPU.  For devices with single core systems, depending on the quality of the GPU, this could put a heavier  workload on the CPU.  Many Android phone makers are trying to build systems that cost less to produce and will introduce lower power versions.  Samsung is notorious for doing this with their GPUs.  Almost every phone they have there is a premium GPU version and an intro GPU version.

If you are still loading a bunch of sounds, they very well could be taxing the CPU. You might want to consider several options:

  1. preload the sounds that get used frequently, in particular at times when the things are slow (like showing  a menu).

  2. Make sure to use 11khz, mono sounds.  They take up less memory, take less time to decode and are easier to play back, in particular for sounds that play frequently. 

  3. Try a different audio format.  Sometimes the codec’s installed are not necessarily from Google and some maybe easier to digest on some devices.

There are so many different android devices made by a bunch of different companies who contract other makers to build the parts and then they fork a version of Android for their device, customize it, then let the carriers (Verizon, AT&T etc.) to add in their own drivers and such.  It makes for a tough mess to build and support for.

Rob