A2DP playback pauses immediately after pushing play when using "Respond to buttons"

[infernix]

Note, I did already submit this through the bug submit form, but I couldn't find its results so I'm just posting for completeness sake.

 

Phone: Oneplus One, Samsung Relay 4G

OS: Stock CM11S and/or CM11 nightlies

Poweramp version: 2.0.9 build 559

 

I'll start off by saying that I have had this bug on various versions of Cyanogenmod and various phones for as long as I can remember, I only report it now because I'm getting tired of it

 

When "Respond to Buttons" is enabled and my phone is paired with my bluetooth car radio, whenever I press play on the Poweramp widget on my homescreen (or inside Poweramp itself), it pauses immediately after. When I quickly press play again, everything is fine.

 

When "Respond to Buttons" is disabled, pressing play works as expected.

 

Full logs are here: http://pastebin.com/bP2k4VZr

 

The points of attention are the Audioflinger start and pause events. In the problem case, we see:

 

08-14 13:24:06.502 D/AudioFlinger(  241): start(4097), calling pid 25264 session 1016

08-14 13:24:06.752 D/AudioFlinger(  241): pause(4097), calling pid 25264

08-14 13:24:17.132 D/AudioFlinger(  241): start(4097), calling pid 25264 session 1017

08-14 13:24:17.282 D/AudioFlinger(  241): pause(4097), calling pid 25264

08-14 13:24:25.662 D/AudioFlinger(  241): start(4097), calling pid 25264 session 1018

08-14 13:24:25.892 D/AudioFlinger(  241): pause(4097), calling pid 25264

 

In the correct case, we see:

 

08-14 13:25:19.262 D/AudioFlinger(  241): start(4097), calling pid 25264 session 1023

08-14 13:25:25.462 D/AudioFlinger(  241): pause(4097), calling pid 25264

08-14 13:25:33.872 D/AudioFlinger(  241): start(4097), calling pid 25264 session 1026

08-14 13:25:40.602 D/AudioFlinger(  241): pause(4097), calling pid 25264

08-14 13:25:48.332 D/AudioFlinger(  241): start(4097), calling pid 25264 session 1027

08-14 13:25:52.462 D/AudioFlinger(  241): pause(4097), calling pid 25264

 

 

The big difference between the two that I can see is the many AVCRP events in the problem case, notabliy RCC_CHANGED_ACTION.

 

I'm not sure what is happening here, but maybe the bluetooth device is sending these actions by itself? I am not touching any buttons on the car stereo at all.

 

If this is actually the cause, would it be possible to add "Ignore" under the Buttons > Bluetooth dialog?

 

If it isn't, I'm at a loss what actually happens, but the full logs should give more insight.