+- Moode Forum (https://moodeaudio.org/forum)
+-- Forum: moOde audio player (https://moodeaudio.org/forum/forumdisplay.php?fid=3)
+--- Forum: Support (https://moodeaudio.org/forum/forumdisplay.php?fid=7)
+--- Thread: BT Audio Sink (/showthread.php?tid=380)
RE: BT Audio Sink - TheOldPresbyope - 08-10-2018
(08-10-2018, 12:16 AM)Tim Curtis Wrote: 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?
Quoting from the A2DP specification (SNK = sink; SRC = source)
Quote:Table 4.2 shows the value of Sampling Frequency field for SBC. For the decoder in the
SNK the sampling frequencies 44.1 kHz and 48 kHz are mandatory to support. The
encoder in the SRC shall support at least one of the sampling frequencies of 44.1 kHz
and 48 kHz.
IIRC, a big source of 48kHz sampled audio is TV.
and, yes, here the Echo is both the initiator of the connection (AVDTP) and the source of the media stream (A2DP).
RE: BT Audio Sink - Tim Curtis - 08-10-2018
Do you have Bluetooth speaker sharing enabled in Audio config?
RE: BT Audio Sink - TheOldPresbyope - 08-10-2018
(08-10-2018, 02:46 PM)Tim Curtis Wrote: Do you have Bluetooth speaker sharing enabled in Audio config?
Prolly I don't understand how that's implemented but naively I had it off. Turning it on makes no obvious difference.
The Bluez config page reports both my phone and my Echo are paired and my Echo is connected. However, the connection isn't reflected in the Playback panel. No bluetooth-related errors show in syslog or moode.log.
Still waiting for the coffee maker to complete the second pot. Need more caffeine before I dive into debugging.
Regards,
Kent
RE: BT Audio Sink - Tim Curtis - 08-10-2018
Try dumping the systemd status or run btmon to try and capture the stream packets from the echo to moOde
systemctl status bluetooth
systemctl status bluealsa
btmon
-Tim
RE: BT Audio Sink - TheOldPresbyope - 08-10-2018
(08-10-2018, 03:17 PM)Tim Curtis Wrote: Try dumping the systemd status or run btmon to try and capture the stream packets from the echo to moOde
systemctl status bluetooth
systemctl status bluealsa
btmon
-Tim
Aha, the dog that didn't bark in the night...
When I connect my Nexus 6P, systemd reports "Started BlueAlsa-Aplay" and Stopping/Stopped when I disconnect it. No such Started/Stopping/Stopped response when I connect/disconnect my Echo.
systemctl doesn't tell me anything interesting comparing the two devices and btmon vomits out the streaming packets which I saw previously in a high-level form with hcidump.
[ADDED in edit] detailed comparison of btmon outputs does show some deviations which I didn't see with the more high level hcidump output. It'll take some time to sort.
Regards,
Kent
RE: BT Audio Sink - Tim Curtis - 08-10-2018
Ok, bluealsa-aplay not starting would explain the "no audio" symptom.
bluealsa-aplay is started by a UDEV rule set. It uses /etc/bluealsaaplay.conf file to determine the audio output device.
/etc/udev/rules.d/10-a2dp-autoconnect.rules
------>/usr/local/bin/a2dp-autoconnect
Try monitoring UDEV during a connection from the Echo.
udevadm monitor -p
If in fact a connection is happening then the monitor will dump out a bunch of properties similar to below. A good connection will have properties that contain the 'NAME' attribute with a mac address as the value.
Code:
KERNEL[6804.792571] add /devices/virtual/input/input2 (input)
ACTION=add
DEVPATH=/devices/virtual/input/input2
EV=100007
KEY=2fc800 1452 0 0 0 0 10300 49e8 c00 e1680 f f8100000 10000ffc
MODALIAS=input:b0005v0000p0000e0000-e0,1,2,14,k71,72,73,8A,8B,A3,A5,A6,A7,A8,AB,AE,C8,C9,D0,161,164,166,16A,16C,18B,18E,18F,190,191,192,193,195,ramlsfw
NAME="5C:8D:4E:91:48:AE"
PRODUCT=5/0/0/0
PROP=0
REL=0
SEQNUM=1240
SUBSYSTEM=input-Tim
RE: BT Audio Sink - TheOldPresbyope - 08-10-2018
(08-10-2018, 05:17 PM)Tim Curtis Wrote: Ok, bluealsa-aplay not starting would explain the "no audio" symptom.
bluealsa-aplay is started by a UDEV rule set. It uses /etc/bluealsaaplay.conf file to determine the audio output device.
/etc/udev/rules.d/10-a2dp-autoconnect.rules
------>/usr/local/bin/a2dp-autoconnect
Try monitoring UDEV during a connection from the Echo.
udevadm monitor -p
If in fact a connection is happening then the monitor will dump out a bunch of properties similar to below. A good connection will have properties that contain the 'NAME' attribute with a mac address as the value.
Code:KERNEL[6804.792571] add /devices/virtual/input/input2 (input)
ACTION=add
DEVPATH=/devices/virtual/input/input2
EV=100007
KEY=2fc800 1452 0 0 0 0 10300 49e8 c00 e1680 f f8100000 10000ffc
MODALIAS=input:b0005v0000p0000e0000-e0,1,2,14,k71,72,73,8A,8B,A3,A5,A6,A7,A8,AB,AE,C8,C9,D0,161,164,166,16A,16C,18B,18E,18F,190,191,192,193,195,ramlsfw
NAME="5C:8D:4E:91:48:AE"
PRODUCT=5/0/0/0
PROP=0
REL=0
SEQNUM=1240
SUBSYSTEM=input
-Tim
Brrr. UDEV. Makes me want to get out my wooden stake and garlic-bulb necklace.
Ok, so when the Nexus 6P connects, I get six stanzas from udevadm:
1) KERNEL [...] add /platform/devices/soc/...
2) UDEV [...] add /platform/devices/soc/...
3) KERNEL [...] add /devices/virtual/input/input9 (input)
4) KERNEL [...] add /devices/virtual/input/input9/event1 (input)
5) UDEV [...] add /devices/virtual/input/input9 (input)
6) UDEV [...] add /devices/virtual/input/input9/event1 (input)
The NAME attribute you mention shows up in the 3rd and 5th stanza.
OTOH, when the Echo connects, I get only two stanzas, below, which to my eye look to have the same kind of content as 1) and 2) for the Nexus 6P.
It should be obvious I'm working beyond the reach of my headlights here.
Regards,
Kent
Code:
i@moode43c:~ $ udevadm monitor -p
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[231835.084054] add /devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
ACTION=add
DEVPATH=/devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11
DEVTYPE=link
SEQNUM=1724
SUBSYSTEM=bluetooth
UDEV [231835.087592] add /devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
ACTION=add
DEVPATH=/devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11
DEVTYPE=link
SEQNUM=1724
SUBSYSTEM=bluetooth
SYSTEMD_ALIAS=/sys/subsystem/bluetooth/devices/hci0:11
SYSTEMD_WANTS=bluetooth.target
TAGS=:systemd:
USEC_INITIALIZED=231835087195
net.ifnames=0RE: BT Audio Sink - Tim Curtis - 08-10-2018
Was hoping for an error of some sort,
We prolly need @Koda59 or @badbat75 to investigate.
-Tim
RE: BT Audio Sink - badbat75 - 08-12-2018
(08-10-2018, 07:37 PM)Tim Curtis Wrote: Was hoping for an error of some sort,
We prolly need @Koda59 or @badbat75 to investigate.
-Tim
Hi all, unfortunately I'm out for my holidays. I can't check for this problem. In the next 2 weeks.
Anyway, it seems that there's a rule that has priority on a2p-connect one. I guess maybe a bluetoothd rule that override it.
Because it create a Bluetooth device instead of an audio one.
RE: BT Audio Sink - dmueller - 08-13-2018
(08-12-2018, 07:45 AM)badbat75 Wrote:(08-10-2018, 07:37 PM)Tim Curtis Wrote: Was hoping for an error of some sort,
We prolly need @Koda59 or @badbat75 to investigate.
-Tim
Hi all, unfortunately I'm out for my holidays. I can't check for this problem. In the next 2 weeks.
Anyway, it seems that there's a rule that has priority on a2p-connect one. I guess maybe a bluetoothd rule that override it.
Because it create a Bluetooth device instead of an audio one.
@Tim Curtis Please advise as to how I can help test. This is excellent news.