[PROBLEM] Bluetooth Audio output (Transmitter)

[Nachteule]

Ah, now we are getting closer

You are missing the link from /dev/serial1 -> /dev/ttyAM0, which is made by an udev rule, namely by the rule /etc/udev/rules.d/99-com.rules

It is present on all my systems (they all based on stone old XBian installations), but strangely not associated with any package. I can only imagine that this file has fallen under the table by mistake at some point.

And with the rework of /etc/init/rpi-bluetooth.conf from 12 days ago it stupidly refers to this link again

Must now consider how this can be solved sensibly

As a workaround to get further you can create the file manually as /etc/udev/rules.d/99-com.rules:

Code:

SUBSYSTEM=="input", GROUP="input", MODE="0660"
SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660"
SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"

SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
        chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
        chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
        chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
'"

KERNEL=="ttyAMA[01]", PROGRAM="/bin/sh -c '\
        ALIASES=/proc/device-tree/aliases; \
        if cmp -s $ALIASES/uart0 $ALIASES/serial0; then \
                echo 0;\
        elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then \
                echo 1; \
        else \
                exit 1; \
        fi\
'", SYMLINK+="serial%c"

KERNEL=="ttyS0", PROGRAM="/bin/sh -c '\
        ALIASES=/proc/device-tree/aliases; \
        if cmp -s $ALIASES/uart1 $ALIASES/serial0; then \
                echo 0; \
        elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then \
                echo 1; \
        else \
                exit 1; \
        fi \
'", SYMLINK+="serial%c"

[Nachteule]

About the delayed start of Kodi:
Please have a look at the file /etc/default/xbmc, parameter WAITFOR=
Here you can specify which services must be running before Kodi is started

So the entry
WAITFOR="bluetoothd"
might help in your case

[ppianigiani]

(1st Jun, 2021 03:20 AM)Nachteule Wrote:  As a workaround to get further you can create the file manually as /etc/udev/rules.d/99-com.rules...

You were right: I've manually created /etc/udev/rules.d/99-com.rules file and restored the original /etc/init/bluetooth.conf script (with the new one it was not working, but I don't know why...) and now I can get BT connection using 5.4.122, so currently I have the same behaviour with 5.4.114 and 5.4.122, and I can use my BT headphones with Kodi in both cases.

Should you need it, here's the current logging from /var/log/upstart/rpi-bluetooth.log file running 5.4.122 (and it looks much better, doesn't it?):

Code:

using /dev/serial1@460800
bcm43xx_init
Set Controller UART speed to 460800 bit/s
Flash firmware /etc/firmware/brcm/BCM4345C0.hcd
Set BDADDR UART: b8:27:eb:66:9e:cb
Set Controller UART speed to 460800 bit/s
Device setup complete
BDADDR need not be set for hci0

Later on, I'll do a few more testing using the WAITFOR parameter in xbmc defaults and let you know.

Many thanks for now!

[Nachteule]

Yes indeed, looks better
But I am irritated that the speed is only set to 460800 bit/s. on my 3B and 4B it is 3000000
Maybe you changed something in the /boot/config.txt?

Here is the code-snipped from /etc/init/rpi-bluetooth.conf that sets the speed

Code:

uart0="`cat /proc/device-tree/aliases/uart0`"
serial1="`cat /proc/device-tree/aliases/serial1`"

if [ "$uart0" = "$serial1" ]; then
    uart0_pins="`wc -c /proc/device-tree/soc/gpio@7e200000/uart0_pins/brcm\,pins | cut -f 1 -d ' '`"
    [ "$uart0_pins" = "16" ] && speed=3000000 || speed=921600
else
    speed=460800
fi

echo "using $dev@$speed"

[ppianigiani]

(1st Jun, 2021 09:05 PM)Nachteule Wrote:  Maybe you changed something in the /boot/config.txt?

I did many tests and tried some changes on /boot/config.txt to have my BT HPs working, so it could be, but no change that now I'm aware of (every time I restored the default values if the BT issue was still present...).
Anyway, from the snippet you sent, it seems in my case uart0 and serial1 are different (and I guess this is unexpected on your side, right?) and thus the speed is set to 460800:

Code:

xbian@xbian ~ $ cat /proc/device-tree/aliases/uart0; echo""
/soc/serial@7e201000
xbian@xbian ~ $ cat /proc/device-tree/aliases/serial1; echo ""
/soc/serial@7e215040
xbian@xbian ~ $

I've also tried the WAITFOR="bluetoothd" option, letting the xbmc service to autostart, but it's not working, I'm getting the very first scenario: thanks to the "sudo -u xbian bluetoothctl connect <dev>" command inside /etc/rc.local, my BT HPs always get connected, but then I can hear sounds only from Kodi's GUI, not from videos or addons.
From what I've seen while testing this, I get the "connection active" prompt from my HPs during the Kodi starting splash and for some reason (no idea why, sorry...) this leads to sound OK from GUI, but no suond from videos or addons (same log entries from my first post).
It seems that the BT device MUST be already connected BEFORE Kodi starts, so I believe that waiting for bluetoothd running is not enough: what do you think?

Anyway, now I'm pretty OK with the current version of my /etc/rc.local running on 5.4.122 (maybe not very elegant, but working):

Code:

printf "\n\n" > /dev/tty1
printf "Starting PulseAudio... " > /dev/tty1
sudo -u xbian /usr/bin/pulseaudio --start
printf "Done\n" >/dev/tty1
printf "Connecting BT headphones: waiting 10 seconds to get the device connected... " >/dev/tty1
sudo -u xbian bluetoothctl connect <myBTdev> &
sleep 10
printf "Done\n" >/dev/tty1
printf "Starting Kodi... " >/dev/tty1
service xbmc start

As you can see, I've forked the BT device connection command, so Kodi will start even if I'm not using my BT headphones (otherwise, the "bluetoothctl connect" command hangs out for ever and Kodi never starts...)

Many thanks!

[Nachteule]

I already suspected before that this does not work via the WAITFOR variable, because rc.local is probably called much too late.

A better alternative than rc.local offers in my opinion the specification of a script in variable USERRUN=, there I have installed the connect with me.

The following example might work for you:

Code:

#!/bin/sh

echo "-----------------------------------"
echo "$(date) $0 $@"
echo "-----------------------------------"

case $1 in

        preload)                # Invoked by /etc/init/xbmc-preload.conf
                case $2 in
                        start)
                                ;;
                        stop)
                                # This should never happen
                                ;;
                esac
                ;;

        xbmc)                   # Invoked by /etc/init/xbmc.conf
                case $2 in
                        start)
                                # Wait some time for bluetoothd
                                for i in $(seq 1 5); do
                                     pgrep bluetoothd >/dev/null && break
                                     sleep 1
                                done
                                # Connect if bluetoothd is running
                                pgrep bluetoothd >/dev/null && bluetoothctl connect <myBTdev> &
                                # Wait until connect has been done
                                for i in $(seq 1 5); do
                                      pgrep bluetoothctl >/dev/null || break
                                      sleep 1
                                done
                                pkill bluetoothctl >/dev/null
                                ;;
                        stop)
                                ;;
                esac
                ;;

        screensaver)            # Invoked by /etc/init/xbmc-screensaver.conf
                case $2 in
                        start)
                                ;;
                        stop)
                                ;;
                esac
                ;;

esac

exit 0

Because of the speed, you probably have the variable dtoverlay=pi3-miniuart-bt activated in /boot/config

[ppianigiani]

(2nd Jun, 2021 04:47 AM)Nachteule Wrote:  Because of the speed, you probably have the variable dtoverlay=pi3-miniuart-bt activated in /boot/config

Once more you were right: I disabled that option and now my serial1 too gets connected @3000000:

Code:

using /dev/serial1@3000000
bcm43xx_init
Set Controller UART speed to 3000000 bit/s
Flash firmware /etc/firmware/brcm/BCM4345C0.hcd
Set BDADDR UART: b8:27:eb:66:9e:cb
Set Controller UART speed to 3000000 bit/s
Device setup complete
BDADDR need not be set for hci0

(2nd Jun, 2021 04:47 AM)Nachteule Wrote:  A better alternative than rc.local offers in my opinion the specification of a script in variable USERRUN=, there I have installed the connect with me.

I had many tries, but I was never able to have it working as expected with a USERRUN script.
Let me add that I also had to run "pulseaudio" manually as xbian user (that was not inside your example script), otherwise it never starts automatically and it seems that the "bluetoothctl connect" command must be run as xbian user as well, otherwise my BT HPs never get connected again (because they were paired&trusted by xbian user, I guess).
Anyway, when the USERRUN script is executed at "xbmc start" step, it actually makes xbmc to immediately stop (from the script header, I can see the same script executed as "xbmc stop", curiously even before I can see it executed as "xbmc start"...).
I also tried to execute it at "preload start" step and in this case I get the usual "half-working mode": sounds from GUI are OK, but no sound from videos or addons.

I may be wrong, but in the end I'm afraid this approach can't be applied, as it seems that nothing can be executed in advance of "preload start" phase.
What still puzzles me is what's causing the "half-working" mode, as the "default" PulseAudio sink works fine for the GUI and not for videos or addons, but honestly, with my pretty limited knowledge of Xbian/Kodi, I don't know how to further investigate this...

[Nachteule]

Yes, I was a bit irritated why you start pulseaudio manually, with my configurations it goes by itself

So I went to the bottom of the matter on a nearly unmodified XBian
There is the file /etc/pulse/client.d/00-disable-autospawn.conf, which prevents the autospawn
Strangely I don't have this file, but I have a file 01-enable-autospawn.conf -> /run/pulseaudio-enable-autospawn in that directory. but I'm sure I never changed anything in there. Probably comes from earlier Debian versions

Anyway if you delete the 00-disable-autospawn.conf or set autospawn=yes pulseaudio starts automatically when Kodi is started


What is also strange is that bluetoothctl on the orginal XBian as user xbian tells me that there are no controllers. so I HAVE to run bluetoothctl as root.
Funny again that this works fine on my development system.
To change this I have to extend the file /etc/dbus-1/system.d/bluetooth.conf, adding

Code:

<policy user="xbian">
    <allow send_destination="org.bluez"/>
    <allow send_interface="org.bluez.Agent1"/>
    <allow send_interface="org.bluez.GattCharacteristic1"/>
    <allow send_interface="org.bluez.GattDescriptor1"/>
    <allow send_interface="org.freedesktop.DBus.ObjectManager"/>
    <allow send_interface="org.freedesktop.DBus.Properties"/>
  </policy>

does the job. Might be a good idea to add this automatically in the future

EDIT:
I'll answer this myself. currently (up to Debian Buster) the user must belong to the group lp or bluetooth so that bluetoothctl can be called as user.
From Debian Bullseye on the user only has to belong to the group bluetooth, which makes more sense.

I noticed that in the default installation the user xbian does not belong to the group bluetooth nor to the group lp.
On my development systems the user xbian is a member of lp as well as bluetooth. Why this is the case I can't say anymore for the life of me

[ppianigiani]

(3rd Jun, 2021 04:16 AM)Nachteule Wrote:  Anyway if you delete the 00-disable-autospawn.conf or set autospawn=yes pulseaudio starts automatically when Kodi is started

OK, I was able to have pulseaudio started automatically with Kodi, but in this case I was never able to have my BT HPs working fine.

From all the testing I've made, in order to have Kodi's GUI and videos&addons sounds on my BT HPs, it seems there are 2 strict conditions that must be met:

1. pulseaudio MUST be already running when kodi starts
2. 'bluetoothctl connect <dev>' command MUST be executed when pulseaudio is already running
   

I guess I can sort of explain the second point (I suspect that a 'pulseaudio' sink MUST already exist in order to successfully connect a BT output device) and I easily tested it on my 'rc.local approach': swapping the execution order, with "bluetooth connect <dev>" command before "pulseaudio --start", no way I can get sounds from my HPs, while the other way around always works fine.

I'm not sure of the second point, but I've tested it in 2 different ways:

• running kodi service with autostart and pulseaudio with autospawn=yes, while executing "bluetoothctl connect" from /etc/rc.local => doesn't work, no sound from HPs, neither the "connection active" prompt
• running kodi service with autostart and pulseaudio with autospawn=yes, while executing "bluetoothctl connect" from USERRUN script, with option "xbmc start" =>doesn't work either, no sound from HPs, neither the "connection active" prompt
  

The point is that when pulseaudio is automatically started with kodi, it's actually started AFTER kodi (pulseaudio pid always higher than kodi pid) and that's why I'm supposing pulseaudio MUST be already running when kodi starts to have it working fine, even if I can't explain why. Does this make any sense to you?

Many thanks!

EDIT
I've added one more test:

• pulseaudio and kodi service started from /etc/rc.local
• "bluetoothctl connect <dev>" executed from USERRUN script, with option "xbmc start"
  

In this case, my HPs never get connected, Kodi crashes immediately and I never see the GUI...
This seems quite a confirmation of the first condition, but once more I can't explain why.

[Nachteule]

This is all really quite strange.

In my development system (but only there) it also happens very rarely that Kodi crashes at startup with segfault and restarts when a BT connect is performed via the userrun script. But since this happens with Kodi 20 Alpha and Debian Bullseye and Kodi also otherwise sporadically crashes at startup I'm not worried yet.

Anyway, with Kodi 19 and Debian Buster the BD connect via the userrun script always works without Kodi crashing, and the output to the BT speakers is also always given, although pulseaudio is always started automatically only after the start of Kodi. Tested with all Raspberry Pi's available to me (Pi3, Pi3B+, Pi4).

This weekend I modified the BT start scripts again, because I obviously had some errors in thinking how the thing should work. But this has nothing to do with your general problem.

[ppianigiani]

I've made a few more testing with your "standard" approach (xbmc service autostarted, pulseaudio automatically started by Kodi and USERRUN script to connect the BT device) with a slightly modified script, collecting the script output to a log file (otherwise, it won't be collected on any file, right?), like this:

Code:

#!/bin/sh

echo "-----------------------------------" >>~/user-run.log
echo "$(date) $0 $@" >>~/user-run.log
echo "-----------------------------------" >>~/user-run.log

case $1 in

        preload)                # Invoked by /etc/init/xbmc-preload.conf
                case $2 in
                        start)
                                ;;
                        stop)
                                # This should never happen
                                ;;
                esac
                ;;

        xbmc)                   # Invoked by /etc/init/xbmc.conf
                case $2 in
                        start)
                                # Check if process pulseaudio is already running
                                pgrep -a pulseaudio >>~/user-run.log || echo "***ERROR: pulseaudio is not running yet!" >>~/user-run.log

                                # Wait some time for bluetoothd
                                for i in $(seq 1 10); do
                                     pgrep -a bluetoothd >>~/user-run.log && break
                                     sleep 1
                                done
                                # Connect my BT headphones if bluetoothd is running
                                pgrep -a bluetoothd >>~/user-run.log && sudo -u xbian bluetoothctl connect 89:2B:5A:9B:AE:50 &
                                # Wait until connect has been done
                                for i in $(seq 1 10); do
                                      pgrep -a bluetoothctl >>~/user-run.log || break
                                      sleep 1
                                done
                                #pkill bluetoothctl >>~/user-run.log
                                ;;
                        stop)
                                ;;
                esac
                ;;

        screensaver)            # Invoked by /etc/init/xbmc-screensaver.conf
                case $2 in
                        start)
                                ;;
                        stop)
                                ;;
                esac
                ;;

esac

exit 0

This is the script log after a reboot:

Code:

-----------------------------------
Mon Jun  7 16:32:25 CEST 2021 /usr/local/sbin/user-run.sh xbmc stop
-----------------------------------
-----------------------------------
Mon Jun  7 16:32:26 CEST 2021 /usr/local/sbin/user-run.sh xbmc start
-----------------------------------
***ERROR: pulseaudio is not running yet!
2623 /usr/sbin/bluetoothd
2623 /usr/sbin/bluetoothd

First of all, is it expected that the USERRUN script is firstly run as "xbmc stop" and then as "xbmc start"? I didn't expect "stop" first, if not at all...

Then, it seems that pulseaudio is not running yet when the script is executed: I've also try to wait inside the script for pulseaudio to start, but it seems it's always started AT THE END of the script, no matter how long it takes: is this expected too?
So, in the end, this seems to be the real issue cause: pulseaudio not running yet when trying to connect the BT device.
If so, given this should be the normal behaviour of the USERRUN script, I'm wondering how the BT connection works fine on your systems: maybe you're using something different from pulseaudio?

[Nachteule]

(8th Jun, 2021 01:03 AM)ppianigiani Wrote:  First of all, is it expected that the USERRUN script is firstly run as "xbmc stop" and then as "xbmc start"? I didn't expect "stop" first, if not at all...

I had checked this immediately with me, there does not occur, but does what it should

Quote:Then, it seems that pulseaudio is not running yet when the script is executed: I've also try to wait inside the script for pulseaudio to start, but it seems it's always started AT THE END of the script, no matter how long it takes: is this expected too?

That is correct. pulseaudio is only started when an application (Kodi) wants to access it.

Quote:So, in the end, this seems to be the real issue cause: pulseaudio not running yet when trying to connect the BT device.
If so, given this should be the normal behaviour of the USERRUN script, I'm wondering how the BT connection works fine on your systems: maybe you're using something different from pulseaudio?

Actually I don't understand why it doesn't work for you. pulseaudio doesn't care which audio sinks are already present at startup. It always takes the default sink first, which can also be a dummy sink. And if another sink with a higher priority is added later (in your case a bt headset) it will use it.

At least this is how it works with my installations

Of course you should use the pulseaudio default device in Kodi and not explicitly your headset.

I just checked this again:
- System started
- In Kodi Audio set to Pulseaudio (default) -> sound is routed to the TV
- BT speakers turned on (were miraculously connected automatically) -> sound now arrives on the BT speakers
As it should be

[gkusiak]

This thread has been quite an adventure.
I'm expecting my Black Friday treat of a bluetooth earbud set to arrive and was wondering what I may need to do to be able to watch TV late at night without disturbing light sleepers...
has anything changed in the 1y+ since the last post, or will I be a beta tester? (will Pipewire be a help or a hindrance?)

[Nachteule]

For me Bluetooth has always been PITA

In my opinion there are 2 sticking points:

1) Is Pulseaudio already running before Kodi start?
2) Can you connect the headphones successfully?

I don't know what should have changed since the last post. but I just remembered, at that time Debian Buster was still in use.

I should still have the old configuration. I can test it in the next days.

[gkusiak]

(28th Nov, 2022 05:05 AM)Nachteule Wrote:  For me Bluetooth has always been PITA

In my opinion there are 2 sticking points:

1) Is Pulseaudio already running before Kodi start?
2) Can you connect the headphones successfully?

I don't know what should have changed since the last post. but I just remembered, at that time Debian Buster was still in use.

I should still have the old configuration. I can test it in the next days.

Thank you. my earbuds have arrived and I'm eager to test them
(bluetooth has gotten better, but it is still a PITA, I agree)
a2dp installation calls for alsa dependencies - I thought linux generally has evolved to PulseAudio...PipeWire seems to work with both from what I can tell (and has taken video into account from inception as I understand things)...bluez is also in there somewhere/somehow...
to your 2nd point - it would be nice to have a dialog somewhere, but I'm ok with command line activities to a degree. I'd assume that would be a one-time pairing procedure
(is this more for the kodi dev community than here specifically?- https://forum.kodi.tv/showthread.php?tid=366533&highlight=bluetooth+headset )(has kodi v20 addressed this?)