[Galaxy S 5 Original Android Development] sylvisj:
I've noticed the same issue. The best fix I could come up with was to play with the ktoonservativeq governor settings - these changes seem to improve bluetooth stutter (but not completely fix) and don't seem to have hurt battery life noticeably. Surprisingly it hasn't seemed to affect battery life much but *did* noticeably reduce bluetooth stutter. Read on if you want to experiment with it - I'd be interested in more feedback on it. Turning WiFi off also seems to help.

I will say though, another issue I've noticed which affects this stutter is overall system memory usage. It seems CM12 roms have a tendency to leak memory like no other and then run like crap until a reboot or a mass app killing. "System" routinely uses 400-700MB RAM... add in a couple more RAM-hungry apps like Ingress, Clash of Clans, Spotify, or Kindle and you're gonna have a bad time.

Let's see... so first, the theory -

I've noticed it gets stuttery when wifi is being used heavily and that core clockrates are usually low or only one CPU is online but high clockrate when stutter occurs. So, what if I were to make it more eager to throw more processing power at the problem? The default ktoonservativeq governor settings start upping CPU0 clockrate at ~57% load and adds cores at ~58/68/78% load. Makes sense - turbo any online cores when we're using actual CPU, and add additional cores as load gets too much for one to handle. But what if the threshold for boost is a bit too high - what if it that particular boost point is above the threshold at which we start hitting stutter? In theory it shouldn't be an issue until we max out a core and tasks have to wait, but as we've all known from CM12 nightlies, this is not a perfect world.

Well, first, let's investigate CPU usage a bit... there's an app for that, OS Monitor. With these settings, before starting bluetooth playback, I'm around 10-30% CPU usage and 1-3 cores as apps spike then idle. Kindle and Inbox both seem to completely smash the CPU while they do syncing... and they sync often. With Bluetooth playback, Bluetooth Share adds anywhere between 2-10% CPU usage. Now fire up a game like Ingress or Clash of Clans to throw into the mix and, well, you're gonna have a bad time. Ingress alone easily adds 12.5-30% load depending on what I'm doing. Now, this is a small sample of the apps I usually have running (even if background)... so it's easy to see how sheer multi-tasked load might get overwhelming. I had read ART is far better than Dalvik at handling SMP loads, so why not let it do its thing?

So, I figured a different strategy would be worth a try - instead of ramping up clock first, instead ramp up cores to better handle additional parallel threads THEN ramp up clocks if more processing power is still needed. That led to the below settings. Instead of waiting 'til we're already at 58% system load to online a core, why not just add one earlier? If its task finishes quickly it'll just quickly offline again. If that wasn't sufficient, another core will be onlined, so on. Given how most of the processes running on my phone are lighter-weight background processes with the occasional heavy foreground task (which is already covered well by Boost ramping up CPU0 clock when I touch the screen), this seemed like a great strategy. I'd even argue it has the potential to be more energy efficient given it theoretically uses 4 cores @ 300mhz before it uses 2 cores @ max clock, but this will probably depend on a user's workload.

(Note: Stutter is still almost 100% influenced by wifi activity, it seems. Any time my wifi is seeing heavy traffic or doing scans for Sensorly, bluetooth starts stuttering.)

(Note 2: lockout_2nd_core_hotplug_screen_off/on does not seem to work - I frequently still run into 3 cores offline.)

down_threshold_screen_off 40

down_threshold_screen_off_hotplug_1 20

down_threshold_screen_off_hotplug_2 30

down_threshold_screen_off_hotplug_3 40

down_threshold_screen_on 40

down_threshold_screen_on_hotplug_1 20

down_threshold_screen_on_hotplug_2 30

down_threshold_screen_on_hotplug_3 40

lockout_2nd_core_hotplug_screen_off 1 (see note 2)

lockout_2nd_core_hotplug_screen_on 1 (see note 2)

no_extra_cores_screen_off 0 (can't test if this actually made an impact - can't see core status when screen is off)

up_threshold_screen_off 45

up_threshold_screen_off_hotplug_1 25

up_threshold_screen_off_hotplug_2 35

up_threshold_screen_off_hotplug_3 45

up_threshold_screen_on 45

up_threshold_screen_on_hotplug_1 25

up_threshold_screen_on_hotplug_1 35

up_threshold_screen_on_hotplug_1 45