BT Audio Sink

[dmueller]

Hey Folks --

Have been looking forward to 4.2 and the updated BT Audio Stack.  I'm currently using Moode around the house, and would like to get it to work with my Amazon Echo.  I have Librelec with a customized setup script which redirects the bt audio out my HifiBerry DAC + (RPI 3+) which works flawlessly.  I'm unable to re-create with 4.2 . Please advise.

For background:  https://www.hifiberry.com/build/guides/c...libreelec/

[Tim Curtis]

Hi,

moOde uses ALSA for all its audio and that link references Pulseaudio so not much help.

Please post details on exactly whats not working and include output from the following cmds:

systemctl status bluetooth
systemctl status bluealsa

-Tim

[TheOldPresbyope]

Hey Folks --

Have been looking forward to 4.2 and the updated BT Audio Stack.  I'm currently using Moode around the house, and would like to get it to work with my Amazon Echo.  I have Librelec with a customized setup script which redirects the bt audio out my HifiBerry DAC + (RPI 3+) which works flawlessly.  I'm unable to re-create with 4.2 . Please advise.

For background:  https://www.hifiberry.com/build/guides/c...libreelec/

@dmueller

You inspire me to take another look at my Echo. I tried and failed in the past to use it as an input to moOde. IIRC, pairing worked; connecting apparently worked; yet moOde was mute.

It wasn't clear to me at the time what was going astray. I had a conjecture and even took a first swing at packet sniffing but then laid this project aside.

Candidly, the grandkids use the Echo more than my SO and I do. Still, it'd be nice to make it work if only for the bragging rights

Regards,
Kent

[dmueller]

Hi,

moOde uses ALSA for all its audio and that link references Pulseaudio so not much help.

Please post details on exactly whats not working and include output from the following cmds:

systemctl status bluetooth
systemctl status bluealsa

-Tim

Hey Tim,

Thanks for the quick response.  I'm pairing my Amazon Echo to the RPI 3 with a HifiBerry AMP+ onboard.  As you know, the HiFiBerry Drivers need to run as the DAC+ for audio to work (not AMP/AMP+), and Airplay and BT from phone, etc all works flawlessly. 

The Echo is successfully paired, yet I don't get any audio out of the Speakers attached to the AMP card.  For consistency, I've also tried a regular RP3 w/HiFiBerry DAC+ card on it, same results.

Very interested to troubleshoot, to please let me know how I can help.

Output as requested:
pi@PorchAudio:~ $ systemctl status bluealsa
● bluealsa.service - BluezAlsa proxy
   Loaded: loaded (/etc/systemd/system/bluealsa.service; disabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-08-08 20:41:12 EDT; 2min 45s ago
 Main PID: 956 (bluealsa)
   CGroup: /system.slice/bluealsa.service
           └─956 /usr/bin/bluealsa -p a2dp-source -p a2dp-sink

Aug 08 20:41:12 PorchAudio systemd[1]: Started BluezAlsa proxy.

pi@PorchAudio:~ $ systemctl status bluetooth
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; disabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-08-08 20:41:11 EDT; 1min 43s ago
     Docs: man:bluetoothd(8)
 Main PID: 923 (bluetoothd)
   Status: "Running"
   CGroup: /system.slice/bluetooth.service
           └─923 /usr/sbin/bluetoothd --noplugin=sap

Aug 08 20:41:11 PorchAudio systemd[1]: Starting Bluetooth service...
Aug 08 20:41:11 PorchAudio bluetoothd[923]: Bluetooth daemon 5.49
Aug 08 20:41:11 PorchAudio systemd[1]: Started Bluetooth service.
Aug 08 20:41:12 PorchAudio bluetoothd[923]: Starting SDP server
Aug 08 20:41:12 PorchAudio bluetoothd[923]: Bluetooth management interface 1.14 initialized
Aug 08 20:41:12 PorchAudio bluetoothd[923]: Endpoint registered: sender=:1.11 path=/A2DP/SBC/Source/1
Aug 08 20:41:12 PorchAudio bluetoothd[923]: Endpoint registered: sender=:1.11 path=/A2DP/SBC/Sink/1
Aug 08 20:42:46 PorchAudio bluetoothd[923]: Endpoint registered: sender=:1.11 path=/A2DP/SBC/Sink/2
Aug 08 20:42:47 PorchAudio bluetoothd[923]: /org/bluez/hci0/dev_44_65_0D_54_00_9A/fd0: fd(19) ready

S Y S T E M    P A R A M E T E R S  

Date and time = 2018-08-08 20:33:02
System uptime = up 4 days, 3 hours, 44 minutes
Timezone = America/New_York
moOde = Release 4.2 2018-07-11

Host name = PorchAudio
ETH0  IP = unassigned
ETH0  MAC = b8:27:eb:91:bb:c9
WLAN0 IP = 192.168.1.86
WLAN0 MAC = b8:27:eb:c4:ee:9c
WiFi country = US

HDWR REV = Pi-3B 1GB v1.2
SoC = BCM2835
CORES = 4
ARCH = armv7l
RASPBIAN = 9.4
KERNEL = 4.14.54-v7+
KTIMER FREQ = 100 Hz
USB BOOT = enabled
Warranty = OK

Audio information
Input Processing
Source: 
http://stream-tx3.radioparadise.com/aac-320
Encoded at: 
VBR compression
Decoded to: 
bit, , 0 bps
DSP Operations
Resampling: 
off
Crossfeed: 
off
Equalizer: 
Graphic EQ: (off), Parametric EQ: (off}
Crossfade: 
0 seconds
Other: 
Volume normalize (no}, Replaygain (off)
Chip options: 
FIR interpolation with de-emphasis, gain=0 dB, boost=0 dB
Volume ctl: 
Software (MPD 32-bit float with dither)
Output Stream
Destination: 
Local
Encoded at: 
16 bit, 44.1 kHz, Stereo, 1.411 mbps
Audio Device
Device: 
HiFiBerry DAC+ Pro
Chip: 
Burr Brown PCM5122
Interface: 
I2S

[dmueller]

Hey Folks --

Have been looking forward to 4.2 and the updated BT Audio Stack.  I'm currently using Moode around the house, and would like to get it to work with my Amazon Echo.  I have Librelec with a customized setup script which redirects the bt audio out my HifiBerry DAC + (RPI 3+) which works flawlessly.  I'm unable to re-create with 4.2 . Please advise.

For background:  https://www.hifiberry.com/build/guides/c...libreelec/

@dmueller

You inspire me to take another look at my Echo. I tried and failed in the past to use it as an input to moOde. IIRC, pairing worked; connecting apparently worked; yet moOde was mute.

It wasn't clear to me at the time what was going astray. I had a conjecture and even took a first swing at packet sniffing but then laid this project aside.

Candidly, the grandkids use the Echo more than my SO and I do. Still, it'd be nice to make it work if only for the bragging rights

Regards,
Kent

Yea it works great with the Librelec and the scripty thing in posted in the link.  But that's it.  I'm not sure if it's a PulseAudio versus ALSA or what.  There's some tiny nuance that's causing this to fail.

[Tim Curtis]

I'm a bit confused as to whats source and whats sink. Which one is supposed to be the speaker?
Echo --> moOde
moOde --> Echo

?

[dmueller]

I'm a bit confused as to whats source and whats sink. Which one is supposed to be the speaker?
Echo --> moOde
moOde  --> Echo

?

Oooh sorry.  moOde is the speaker.  Echo is the source.

[Tim Curtis]

Are there any error error messages, logs or diagnostics from the Echo?

-Tim

[TheOldPresbyope]

Are there any error error messages, logs or diagnostics from the Echo?

-Tim

Nah. Amazon hides all the messy stuff from us.

I've gotten back to my Amazon Echo and tried connecting again while monitoring just the Bluetooth AVDTP packets ($ sudo hcidump avdtp).

Everything in the negotiations looks the same as it does when I connect one of my Android devices until the point where the initiator (e.g., Echo) tells the acceptor (e.g., the moOde Bluetooth stack) which initiator and acceptor stream endpoints will be connected together and with what settings. I've posted the detailed dumps to pastebin (https://pastebin.com/2Db2GiHr) to keep this post short. 

In a nutshell, although the same endpoints are chosen, the Android devices select 44.1kHz for the connection and the Echo selects 48kHz. One would think this would be fine with the moOde Bluetooth stack because it's already advertised this capability

Code:

Media Codec - SBC
     16kHz 32kHz 44.1kHz 48kHz

Then when the stream is actually opened, the Android devices increment the transaction number and begin transmitting media packets as payload type (pt) = 96 with synchronization source (ssrc) = 0 while the Echo resets the transaction number to 0 and begins transmitting media packets as pt=1 with ssrc=1. I don't know how the transaction number is used. The ssrc setting seems like it should be irrelevant in this context.*

The payload type may be the smoking gun here. Recall the trouble with PC Bluetooth connections. I'll try disabling the type check in bluez-alsa again. If that works, I need to reopen an old issue on Arkq's bluez-alsa github repo. He has argued (and I think with good justification) that the A2DP spec calls for payload type=96 (usage dynamically defined by apps) and checks for it. According to the RTP Profile for A/V, the payload type=1 is reserved.

Regards,
Kent

*From the AVDTP spec

SSRC field is only used for multicast application, because SSRC field identifies the source-node ID on the specific Media transport session. 

I see ssrc is defined but not used in the bluez-alsa repo.

[Tim Curtis]

Possibly the 48K format that Echo is sending might be whatscausing no audio output from the Linux BT stack. I always thought that BT was limited to 44.1K.

If the stack is barfing on 48K there should be log errors somewhere.

This is Echo ---> moOde right?