[PROBLEM] Can't connect SPDIF/BT transmitter to moOde

[romain]

The result of step 1 suggests that bluealsa-aplay has not been started by Bluetooth or has crashed. It's the player that Bluetooth launches when a client connection is successfully established and is what moOde looks for to trigger displaying the BT overlay screen.

After step 1 you can try:
bluealsa-aplay -l or --help for more options.

Also if it's not running (pgrep bluealsa-aplay = blank) you can try to run it manually using the MAC address of the CM150 to see if it prints any errors.
sudo systemctl start bluealsa-aplay@MAC_ADDR
systemctl status ...

Hello,

Code:

bluealsa-aplay -l

lists CM150 as a playback BT device ; it returns device name UG-SPDIF-TX as well as MAC address and type audio-card.

However, unless I connect another BT source to moOde, I have to manually start the bluealsa-aplay@MAC_ADDR.service to get it to work and see the BT overlay screen with the device name displayed.

I also have to manually stop the bluealsa-aplay@MAC_ADDR.service otherwise BT overlay remains displayed without device name when the CM150 is powered off and moOde doesn't fallback to MPD.

As for latency, with a length of 20 ms set for output buffer, sound and picture are almost perfectly synchronised without noticeable dropouts

So, the problem now is that the bluealsa-aplay service is not starting nor stopping automatically with the CM150.

Romain

[Tim Curtis]

Very odd that its not being started or stoped automatically.

The auto start/stop action is handled by UDEV. The rule file is:

Code:

/etc/udev/rules.d/10-a2dp-autoconnect.rules

You can monitor UDEV events via the command below but I have very little expertise in troubleshooting this part of Linux.

Code:

pi@moode:~ $ udevadm --help
udevadm [--help] [--version] [--debug] COMMAND [COMMAND OPTIONS]

Send control commands or test the device manager.

Commands:
 info          Query sysfs or the udev database
 trigger       Request events from the kernel
 settle        Wait for pending udev events
 control       Control the udev daemon
 monitor       Listen to kernel and udev events
 test          Test an event run
 test-builtin  Test a built-in command

See the udevadm(8) man page for details.
pi@moode:~ $

[romain]

Hello,
the problem is that the existing udev rule for bluetooth device doesn't match the kernel event triggered by the CM150. I'll try to write an appropriate udev rule.
Romain

[Tim Curtis]

Hello,
the problem is that the existing udev rule for bluetooth device doesn't match the kernel event triggered by the CM150. I'll try to write an appropriate udev rule.
Romain

Interesting. It certainly wasn't obvious what was causing the issue.

[romain]

Hello,
the problem is that the existing udev rule for bluetooth device doesn't match the kernel event triggered by the CM150. I'll try to write an appropriate udev rule.
Romain

Interesting. It certainly wasn't obvious what was causing the issue.

when the CM150 is powered on 

Code:

udevadm monitor -s bluetooth

returns the following lines almost each second

Code:

KERNEL[75254.611334] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
KERNEL[75255.068181] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
KERNEL[75257.171353] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)
KERNEL[75257.632178] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)
KERNEL[75259.732834] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
KERNEL[75260.212532] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
KERNEL[75262.295156] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)
KERNEL[75262.748189] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)
KERNEL[75264.856413] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
KERNEL[75265.324182] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
KERNEL[75267.416460] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)
KERNEL[75267.872176] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)

an explanation of what /dev/ttyAMA0 is and how it is related to bluetooth:
https://raspberrypi.stackexchange.com/qu...ev-ttyama0
https://raspberrypi.stackexchange.com/questions/45570/how-do-i-make-serial-work-on-the-raspberry-pi3-pizerow-pi4-or-later-models/45571#45571 

I've remotely enabled the hciuart.service which is disabled by default as well as the serial port hardware with raspi-config in order to get and use /dev/serial1 instead of /dev/ttyAMA0.

I'll see how things behave when I'm back home

[TheOldPresbyope]

@romain

It will be interesting to hear what you come up with.

Here's more grist for your mill.

Start udevadm on an Pi4B running moOde 8.2.4 player---with BT controller enabled and Pairing agent turned on---and then scan, pair, and connect from my Pixel 6a phone.

Code:

pi@m824p4b:~ $ udevadm monitor -s bluetooth
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[7994.513293] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)
UDEV  [7994.518096] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)

When I then disconnect the phone I see the following two lines added, as expected

Code:

KERNEL[8281.508354] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)
UDEV  [8281.516595] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)

Contrast that with the output I get when I scan, pair, and then connect from another moOde 8.24 player (on a Pi3A+)

Code:

pi@m824p4b:~ $ udevadm monitor -s bluetooth
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[8755.970141] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
UDEV  [8755.974968] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
KERNEL[8762.224259] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
UDEV  [8762.227890] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
KERNEL[8804.418090] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)
UDEV  [8804.423059] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)

The first four lines (device hci0:11) appear when I paired, the last two lines (device hci0:12) appear when I connected.

Looking at the tail of /var/log/kern.log I see

Code:

Jan 19 13:31:58 m824p4b kernel: [ 7994.402194] Bluetooth: hci0: ACL packet for unknown connection handle 12
Jan 19 13:31:58 m824p4b kernel: [ 7994.623526] Bluetooth: hci0: ACL packet for unknown connection handle 12
Jan 19 13:31:58 m824p4b kernel: [ 7994.651044] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:32:02 m824p4b kernel: [ 7998.108644] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:32:02 m824p4b kernel: [ 7998.227364] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:32:02 m824p4b kernel: [ 7998.228620] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:32:02 m824p4b kernel: [ 7998.381153] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:32:05 m824p4b kernel: [ 8001.229134] input: Pixel 6a (AVRCP) as /devices/virtual/input/input4
Jan 19 13:36:45 m824p4b kernel: [ 8281.530293] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:44:40 m824p4b kernel: [ 8756.639904] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:44:40 m824p4b kernel: [ 8756.658637] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:45:28 m824p4b kernel: [ 8804.635065] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:45:28 m824p4b kernel: [ 8804.653827] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:45:29 m824p4b kernel: [ 8805.166811] input: m824p3a Bluetooth (AVRCP) as /devices/virtual/input/input5

Maybe my glasses are extra smudged today but I don't see a difference between my udevadm entries and yours. Are you proposing that there's something going on behind the scene?

Regards,
Kent

[romain]

@romain

It will be interesting to hear what you come up with.

Here's more grist for your mill.

Start udevadm on an Pi4B running moOde 8.2.4 player---with BT controller enabled and Pairing agent turned on---and then scan, pair, and connect from my Pixel 6a phone.

Code:

pi@m824p4b:~ $ udevadm monitor -s bluetooth
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[7994.513293] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)
UDEV  [7994.518096] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)

When I then disconnect the phone I see the following two lines added, as expected

Code:

KERNEL[8281.508354] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)
UDEV  [8281.516595] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)

Contrast that with the output I get when I scan, pair, and then connect from another moOde 8.24 player (on a Pi3A+)

Code:

pi@m824p4b:~ $ udevadm monitor -s bluetooth
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[8755.970141] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
UDEV  [8755.974968] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
KERNEL[8762.224259] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
UDEV  [8762.227890] remove   /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:11 (bluetooth)
KERNEL[8804.418090] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)
UDEV  [8804.423059] add      /devices/platform/soc/fe201000.serial/tty/ttyAMA0/hci0/hci0:12 (bluetooth)

The first four lines (device hci0:11) appear when I paired, the last two lines (device hci0:12) appear when I connected.

Looking at the tail of /var/log/kern.log I see

Code:

Jan 19 13:31:58 m824p4b kernel: [ 7994.402194] Bluetooth: hci0: ACL packet for unknown connection handle 12
Jan 19 13:31:58 m824p4b kernel: [ 7994.623526] Bluetooth: hci0: ACL packet for unknown connection handle 12
Jan 19 13:31:58 m824p4b kernel: [ 7994.651044] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:32:02 m824p4b kernel: [ 7998.108644] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:32:02 m824p4b kernel: [ 7998.227364] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:32:02 m824p4b kernel: [ 7998.228620] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:32:02 m824p4b kernel: [ 7998.381153] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:32:05 m824p4b kernel: [ 8001.229134] input: Pixel 6a (AVRCP) as /devices/virtual/input/input4
Jan 19 13:36:45 m824p4b kernel: [ 8281.530293] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:44:40 m824p4b kernel: [ 8756.639904] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:44:40 m824p4b kernel: [ 8756.658637] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:45:28 m824p4b kernel: [ 8804.635065] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:45:28 m824p4b kernel: [ 8804.653827] Bluetooth: Unexpected continuation frame (len 0)
Jan 19 13:45:29 m824p4b kernel: [ 8805.166811] input: m824p3a Bluetooth (AVRCP) as /devices/virtual/input/input5

Maybe my glasses are extra smudged today but I don't see a difference between my udevadm entries and yours. Are you proposing that there's something going on behind the scene?

Regards,
Kent

Kent,
for the while I'm stuck because enabling hciuart.service and serial interface didn't change anything to the actual situation :\ I have to do more researches
Romain

[romain]

Hello,
I couldn't find an appropriate UDEV rule to trigger the bluealsa-aplay service to get the CM150 working other than manually :\ If someone else has an idea...
Romain

[TheOldPresbyope]

Hello,
I couldn't find an appropriate UDEV rule to trigger the bluealsa-aplay service to get the CM150 working other than manually :\ If someone else has an idea...
Romain

I suggest you visit the BluezAlsa repo. From its ReadMe.md,

 BlueALSA registers all known Bluetooth audio profiles in BlueZ, so in theory every Bluetooth device (with audio capabilities) can be connected.
...and...
The heart of BlueALSA is the daemon bluealsa which interfaces with the BlueZ Bluetooth daemon bluetoothd and the local Bluetooth adapter. It handles the profile connection and configuration logic for A2DP, HFP and HSP and presents the resulting audio streams to applications via D-Bus.

Sorry, I don't have time right now* to sift through that repo's existing issues and discussions but I suspect either your situation has already been covered or can get resolved there.

Regards,
Kent

*Public service announcement: keep your blood pressure in check; especially if you're an oldster like me. My partner and I have been devoting almost all our time to helping a friend who suffered a stroke last week, precipitated by her blood pressure. The consequences are life-changing.

[romain]

Kent,

I don't know if this is related to the problem I encounter with CM150 adapter but, at first glance, I noticed that moOde implements an outdated bluez-alsa version (v3.0.0-2moode1) compared to v4.0.0 released months ago on GitHub.

I'll read further the bluez-alsa docs.

Thanks a lot for your time,
Romain