CPU load effect of Bluetooth connections
July 14, 2016 8:33 AM   Subscribe

I hook my phone up to a variety of different Bluetooth speakers and headphones. I notice that some of them produce effects consistent with the device being under very heavy CPU load and wonder (a) why, and (b) if there's a way to mitigate the effect.

I have a Samsung Galaxy S4 (I'm perpetually a few versions back on current hardware) running CM12.1, and under most circumstances my phone is pretty peppy. The main exception is when it's connected to a single, specific media device: the ZFLIN G7 Bluetooth FM transmitter. I haven't actually done a specific test of my phone's load stats (under top or vmstat), but the music sometimes breaks up in a way which sounds a lot like what happens when the CPU is overworked, and if I try to use the device (while parked, of course) after such an occurrance, it's often very sluggish.

Most of the audio devices I have my phone talk to implement BT4 or higher; this specific device is BT2.1+EDR. I think pretty much all of my devices use the AVCTP and AVDTP profiles (they're ordinary wireless audio of the speaker and headphone variety, most with music-control buttons). is the difference in Bluetooth versions likely to cause the discrepancy in load? And if so, is there a way to configure BT2.1 to be less ridiculously resource-intensive?
posted by jackbishop to Technology (2 answers total)
The issue may be that the audio must be transcoded to a different format for the older device. This can require the CPU to be used and can cause lagging, dropped audio, and higher battery usage. Upgrade the device to a newer one if you can.
posted by kindall at 3:09 PM on July 14, 2016

Response by poster: OK, I followed the instructions here to determine the AVDTP capabilities both of the G7 and of one of my less problematic wireless audio devices. However, both seem to be reporting about the same thing --- SBC codec only, capable of all sampling frequecies, channel modes, &c., bitpool range 2-53. The only difference between the two seems to be that the "good" device also implements SCMS-T content protection, but that doesn't seem like it should make a difference.

Might not rule some sort of transcoding issue out totally, but AFAICT since they implement the same codec they should require equal amounts of phone-based transcoding load.
posted by jackbishop at 3:52 PM on July 15, 2016

« Older Student loan nightmare. Will a Lawyer help?   |   Improv games for irreverant grown-ups on... Newer »
This thread is closed to new comments.