01-10-2020, 05:14 PM
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
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
