Bluetooth not working with Chromebook

[OpiVanKnobi]

Hi there, I got a Moode player running on a RPi 3B with a HifiBerry DAC and things work fine, except IPv6 (but that's another story) and more importantly Bluetooth from a Chromebook. Here's what I tried so far:

Working:

- Android Phone → Moode

- Android Tablet → Moode

- Chromebook → BT headset

Not working:

- Chromebook → Moode

The BT pairing works fine, the connection is displayed in the UI, but unlike the connections from Android, there's just no output at all. I tried re-pairing and various reboots already to no avail.

What are some CLI tools I could use on the RPi to look at the BT connections to see how they might differ maybe? Where to start debugging this?

[TheOldPresbyope]

@OpiVanKnobi

There's a boatload of low-level Bluetooth tools. Try "man -k bluetooth" to see what's already built into moodeOS. There's lots of blogs, tutorials, etc., out there on how to use them to solve trivial problems (try a few keywords in your favorite search engine). Solving hard problems, not so much.

In my case, I had a similar problem trying to get my first-generation Amazon Echo to stream to my moOde player. The Echo would drive my JBL Flip2 BT speaker, it would drive my wireless headset, but it wouldn't drive my moOde player despite apparently being connected. All my other BT sources work fine.

I spent a lot of time fruitlessly looking for the "smoking gun" (or should I say the "dog that didn't bark in the night") in various logs and dumps. I was never able to resolve the issue. I'm pretty good at debugging software and hardware but this is one that got away. 

Rumor has it that some late-generation Echo will work but I'm not willing to buy one just to find out. Now that the novelty has worn off I hardly use the one I already have.

Fortunately, you're working with a Chromebook and not just a "blackbox" device so you have a chance to see both ends of the Bluetooth traffic. 

Good luck.

Regards,
Kent

PS - my speculation is that both the Echo and moOde are waiting to receive, so nothing happens.

[OpiVanKnobi]

Oh boy, I'm now several hours in and I'm not sure how close I am to solving this mystery. There are many, many problems with RPi and bluetooth it seems, so here's what I gathered so far:

btmon: I recorded a diff between the Chromebook and my Pixel phone and they look pretty similar. Of note was that the Chromebook was sending audio with 48kHz instead 44.1, but that shouldn't be it, right?

What I can see is that tons of data is flowing in once the playback starts, and "silence" is pretty visually distinct, so I'm pretty sure the audio is being received fine from the bluetooth stack's perspective.

I've figured out that I can ignore everything about pulseaudio, because moode is using bluealsa w/o pulseaudio.

Then I ran bluealsa-aplay directly, and for my phone it shows up this (but stays silent on the Chromebook)

bluealsa-aplay -vv 00:00:00:00:00:00
Selected configuration:
  HCI device: hci0
  PCM device: default
  PCM buffer time: 500000 us
  PCM period time: 100000 us
  Bluetooth device(s): ANY
  Profile: A2DP
Used configuration for 33:22:11:XX:XX:XX:
  PCM buffer time: 500000 us (88200 bytes)
  PCM period time: 100000 us (17640 bytes)
  Sampling rate: 44100 Hz
  Channels: 2


Turning on syslog logging, I see it's being spammed with these (chromebook only, not Android)
/usr/bin/bluealsa: Unsupported RTP payload type: 1
/usr/bin/bluealsa: Unsupported RTP payload type: 1
/usr/bin/bluealsa: Unsupported RTP payload type: 1
/usr/bin/bluealsa: Unsupported RTP payload type: 1

@TheOldPresbyope could you check whether the same happens for your Echo? Not sure where Echo or ChromeOS use pulseaudio, they might still have that bug here https://gitlab.freedesktop.org/pulseaudi...issues/591

[OpiVanKnobi]

After some more searching, I found http://moodeaudio.org/forum/showthread.php?tid=358 and yeah, the same fix there works for me. yay!

Audio lag sadly is too much to watch videos on the chromebook and have it use the real speaker. Any quick commands to reduce BT latency? I'm 2m from the device and my other Wifi clients are on 5GHz, so I really shouldn't need much of a buffer for retransmits at all.

[TheOldPresbyope]

Sorry, I think you may have mistaken me for someone who cares about PulseAudio. Don't wish to disappoint, but no.

Not sure what "many, many problems with RPi and Bluetooth" refers to. 

The RTP payload issue was widely discussed in https://github.com/Arkq/bluez-alsa/issues/13 and there is a workaround referenced there. You can try rebuilding bluez-alsa if Tim doesn't already incorporate it. (Check the bluez-alsa build sequence in the moOde build instructions to see.) To reemphasize the point made in the discussion, the fault lies with PulseAudio, not bluez-alsa, hence the need for a workaround.

My Echo has moved on. Maybe if someone gives me a 3rd-generation Echo Dot to play with I'll revisit the issue since I've seen suggestions (no hard facts) it sports new and improved firmware, but other than the dubious fun of yelling selections at Alexa, streaming audio to a moOde player via Bluetooth from an Echo seems irrelevant in my house. (I'd love, however, to program an Echo to reply "I'm sorry, Dave, I'm afraid I can't do that.")

Android devices like my Pixel 3A phone connect and stream to my moOde player just fine. That your Chromebook doesn't shows is yet another illustration how isolated different Google development teams can be.

Good hunting.

Regards,
Kent