For the devices with buffer starvation can you try two things (separately).
1. System::setDSPBufferSize(1024, 4) call this before System::init
2. System::setOutput(FMOD_OUTPUTTYPE_AUDIOTRACK) call this before System::init
Please let me know if either of these options helped, don’t use them both at the same time.

For the devices that crashed, can you please provide the log output leading up to the crash.

Also, for the devices that crash, are you able to get them to crash in our examples?

Hi Mathew,thanks for your help,we try the both ways separately,and both of them are useful to solve the problem,I have to say sorry because it isn’t the “crash”,instead it’s the sample stretching and compressing phenomenon happened when tests on those devices,all the test was based on the examples in the low-level api folder.
We have tracked the problem to the audio driver which those devices used,all of them are OPENSL rather than AUDIOTRACK,and I wander whether FMOD may automatically detects the Android OS version and then call the suitable driver or not??
And these devices are all above Android 4.4,our programmer said only the device’s system is below Android 2.2 then the audio driver would be AUDIOTRACK,it’s a little bit strange here.
Also maybe there is a bug,
[2016-04-22 13:55:39.400] [FMOD Warning] FMOD output type: 16
[2016-04-22 13:55:39.401] [FMOD Warning] FMOD DSP buffer size: 512, buffer num: 4
the log as you can see showed that the DSP buffer size is 512,we never changed the default value,and the API document says the default is 1024,can you tell us what happend here??Thanks a lot.

We have some heuristics that determine which output driver to select based on what the OS tells us. I have a tweak planned for our next 1.08.xx release that should cause the automatic selection to work better for the devices you have listed.