Now I'm down a weird-ass rabbit hole with the code and the behavior.

So there's this problem where the headunit stays stuck in "pause" mode all the time now with the V6 version of the BC127 firmware. This is an issue because, not only do certain commands not work in pause mode, but also the headunit mutes the audio. So even if I decide to live with some of the other problems, I still get no sound so I can't use the Purpletooth Jamboree board as an audio-only bluetooth streamer board.

Now keep in mind that I'm trying to use the board in what they call "Source" mode right now. Meaning: It's the audio source material (ie the empeg's line audio) which streams up to the car stereo head unit. So in this case, it should never have to send AVRCP commands, it should only receive them, right?

But I found out through experimentation why it stays stuck in pause mode. It's because after it pairs up, it needs to send a "play" command to get the stereo to unmute and go into play mode. It won't allow the headunit to even send it a play command, it has to initiate that command itself. Whaaaaaat?

So here's what I'm seeing:
- Head unit pairs with BC127, at which point a few messages appear including this one:
OPEN_OK 11 AVRCP
(note: 11 is the Link ID, in this case "10" would be Link 1, A2DP, and "11" would be Link 1, AVRCP)
- At that point the headunit is stuck in PAUSE mode.
- So at that point I must send the following command to the BC127:
MUSIC 11 PLAY
- This brings the headunit instantly out of "stuck in pause" mode and it starts streaming good audio.

So I added that to my code. But then something else weird.

So now it's booted, paired, I sent the play command, I'm listening to music. Now I want to pause the music.

When I press the Pause button on the headunit touchscreen, then it goes back into "stuck forever in pause mode" again after sending the AVRCP_PAUSE command to the BC127. (Which still has a weird delay and/or never gets sent in "new" mode, but no delay in "old" mode.)

So one thing I can do, is re-send it a "MUSIC 11 PLAY" command again after that. But then my code gets the "AVRCP_PLAY" command looped back and tries to reprocess that as if the user had pressed play. Catch-22 at that point. So I'm having to swallow the inputs right after I send the "MUSIC 11 PLAY".

But here's what I'm wondering: Why the heck doesn't the BC127 do that shit AUTOMATICALLY? In fact, my recollection is that Version 5 of the BC127 firmware did indeed handle that all automatically and never got stuck in pause mode.

Then I'm getting a weirder thing. Might be bugs in my code constantly looping and sending pause/play back and forth (doubt that, though I'm double checking), but I think it's more likely that it might be a symptom of the "delay" problem under the hood. It goes like this: sometimes when I'm playing music and I press the PLAY button on the headunit, then the music turns into staccato noise, basically sounding similar to what a video game sounds like when there is CPU overloading and the game music turns crackly because it can't update the audio output quickly enough. Like this:

"la la la la lakkkkkkkkkklklklklklklkakakakakakakakakakakaka lklklklklklklklkakakakakakaka la al la la la "

So that sounds to me like, whatever is causing the delays is also causing the CPU to hang up and glitch even on the audio stream. Can't tell if it's the headunit's CPU or if it's the BC127's CPU.

Still futzing with it. Really interesting. And frustrating.