2

I noticed that when playing a SFX with soundpool in a thread, it generates a FPS slowdown in the game and when playing the SFX in main thread the game doesn't slow down.

Why soundpool works better playing from mainthread?

This is the play call:

streamID[sound] = soundPool.play(soundID[sound], getSoundEffectsVolume(), getSoundEffectsVolume(), 0, loop, 1);
NullPointerException
  • 36,107
  • 79
  • 222
  • 382
  • How do we know it's not your thread's implementation, or the inter-thread communication scheme? – greeble31 Oct 17 '19 at 20:44
  • @greeble31 my thread is not doing anything special, and it's taking only 1 or 2 ms of CPU each 33 ms of cycle, so it's waiting 31 ms, the thread communication scheme it's the android default scheme, I'm not doing anything special – NullPointerException Oct 19 '19 at 06:55
  • Not sure what you mean by "default scheme"; it would be helpful if you could post more code, or explain exactly what method you call to pass the message. Also, 1.) How are you determining FPS slowdown, 2.) What is the degree of slowdown, 3.) Assuming you are using `GLSurfaceView`, roughly how long does your `onDrawFrame()` take to execute, on average? – greeble31 Oct 19 '19 at 13:10

1 Answers1

6

It is because SoundPool is a darkhorse, it is implemented in native layer. So every time you have call SoundPool.play() you will create new thread internally.
So when you call play right in the UI thread, you will get: 1 main thread + 1 AudioTrack thread (that is created inside play call). When you call play in the worker thread you will get: 1 main + 1 worker + 1 play thread. More threads == less resources left.

Also when you call play in ui thread you will get lower latency. Because there will be only one switch: from ui to audioTrack thread, instead of two: from main to worker, from worker to audiotrack thread.

Oleksandr Albul
  • 1,611
  • 1
  • 23
  • 31