Forum

Full Version: Bluetooth Audio output (Transmitter)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6
(5th Jun, 2016 03:38 AM)IriDium Wrote: [ -> ]Is dtparam=audio=on set as default? If not, then I was running a vanilla RPi3 newly flashed image.

Yes it is

Quote:IMX6
/etc/default/bluetooth
BLUETOOTH_ENABLED=0

Not something I have set

This file is part of bluez package

And it should be enabled automagically by upstart service file /etc/init/imx6-bluetooth.conf

Btw, I cloned this file for RPi3, so there should be same behaviour
FYI: This is default /boot/config.txt
Commenting out dtparam=audio=on was the crucial point missed.

Connected automatically and played first time around.

Disabled onboard BT and used BT Dongle - worked as expected (Had to re-add the BT speaker via bluetoothctl)
(4th Jun, 2016 07:36 PM)IriDium Wrote: [ -> ]So bottom line, the RPi3 BT controller should not be used for audio (Unless you have perforated eardrums or deaf).

I looked a little bit around if this issue is already known, and voila, here it is Smile

And you can found a lot of threads of users having sound issues with onboard BT. All of them are able to solve them by disabling WLAN by "sudo ifdown wlan0".

Maybe you could test it if "sudo ifdown wlan0" helps (unfortunately I'm still not able do connect my speaker using onboard BT Sad)
(5th Jun, 2016 10:29 PM)Nachteule Wrote: [ -> ]Maybe you could test it if "sudo ifdown wlan0" helps (unfortunately I'm still not able do connect my speaker using onboard BT Sad)

Sure, I'll give it a go. (Won't be for a couple of days) I also want to check the permissions. I can't see why access to "lp" (cups and printing) is required for it to work.

However, until the driver/hardware or whatever is solved, it seems rather pointless having BT audio but no wifi or vice versa, or buying additional dongles.

However, I think we are almost there.

I'll be glad when this is solved and put to bed, it's been a right pain!!
RPi3: Just rerun the selections (on a new installation) with the addition of dtparam=audio=on and it worked flawlessly.

The "lp" permissions are required otherwise you get a bluez.error.Failed. Odd.

Even using the onboard BT and WIFI up (But not connected) - the sound was Ok - no glitches or any stutters.

However, using ONLY onboard WIFI (No ethernet) I got the stutters back.

sudo ifdown wlan0 didn't really help in that instance.

However, disabling WIFI in xbian-config and rebooting, it was back to normal usable sound.

Even reconnected automatically on reboot.

IMX6: Is there an equivalant to dtparam=audio=on for the cubox-i as I had the same issue, connected OK but no sound?
I've just tried the "same" on a cubox-i using the onboard BT and the latest image but the quality of the sound was even worse than the RPi at it's worse. I tried disabling the onboard wifi but didn't help

Looking at the solidrun website, seems to suggest that this is a known problem and hasn't really been resolved.

Sensible solution stick to wired. It's better quality and works Cool
(30th Apr, 2016 04:11 AM)Nachteule Wrote: [ -> ]Thanks for this 'mini' Howto. Will help me for a better start with BT (want to build BT dialog for config-xbmc for next Kodi version)
Is there a BT dialog for config-xbmc now?
(7th Feb, 2019 08:17 PM)BreadPit Wrote: [ -> ]
(30th Apr, 2016 04:11 AM)Nachteule Wrote: [ -> ]Thanks for this 'mini' Howto. Will help me for a better start with BT (want to build BT dialog for config-xbmc for next Kodi version)
Is there a BT dialog for config-xbmc now?

Unfortunately no - it's still on my long todo list Sad
Hello all,
I'm an Xbian newbie (as you might understand from the rest of my post... Smile) and I'm trying to use BT headphones connected to my RPi3B+ onboard BT module, running the latest version of Xbian and it seems I'm hitting permissions issues.

So far I was able to:
  • connect my BT headphones to the RPi BT onboard module (using pulseaudio/bluetoothctl)
  • select "ALSA: Playback/recording through the PulseAudio sound server" on Kodi's System > Audio > Audio output device config

When I boot up my RPi, the BT HPs always get connected and once Kodi has automatically started, I can hear beeps&ticks when moving through Kodi's menus, so everything seems to work fine, but when I try to play a video from Kodi or from an addon (i.e. Amazon VOD or YouTube), the audio stops on my BT HPs and after that, no way to get it working again (no more beeps&ticks when moving through Kodi menus).

Then, if I close Kodi and from a ssh console (logged in as xbian user) I kill the "pulseaudio" process, restart it, re-connect my BT HPs using "bluetoothctl" commands and restart kodi (using "kodi start" command), then everything works fine, I can hear perfect audio on my BT HPs when playing a video both through Kodi or through an addon.
This second scenario makes me think I'm hitting some permissions issues on the first scenario, but I was not able to find the cause: I tried to follow all the instructions in this thread, but I found no solution yet.

Here's my system config:

Software
XBian version: Xbian 1.0 (knockout) (kernel: Linux 5.4.114+)
XBMC/Kodi version: 19.1 Matrix
Overclock settings: None

Hardware
Device type and model: Raspberry Pi 3 Model B+
Power supply rating: Output 5V/2.0A
SD card size and make/type: MicroSD HC 32GB - A1
Network: Ethernet eth0 (static setting)
Connected devices (TV, USB, network storage, ...): HMDI monitor


Here's a log file when I can't hear any audio from my BT headphones when playing a video:
kodi.log from NON-working scenario

And here's a log file from the second scenario, when everything works fine, as expected:
kodi.log from working scenario

From what I've seen on the log files, in the first scenario I can see the following log entries:

Code:
2021-05-28 10:38:16.274 T:3137     INFO <general>: CActiveAESink::OpenSink - initialize sink
2021-05-28 10:38:16.274 T:3137    DEBUG <general>: CActiveAESink::OpenSink - trying to open device ALSA:default
2021-05-28 10:38:16.274 T:3137     INFO <general>: CAESinkALSA::Initialize - Attempting to open device "default"
2021-05-28 10:38:16.284 T:3137     INFO <general>: CAESinkALSA::Initialize - Opened device "default"

This seems to be when I can hear sounds from my BT headphones moving thorugh Kodi menus, but when I start playing a video, these are the entries on the log file:

Code:
2021-05-28 10:40:17.329 T:3137     INFO <general>: CActiveAESink::OpenSink - initialize sink
(...)
2021-05-28 10:40:17.536 T:3137     INFO <general>: CAESinkALSA::Initialize - Attempting to open device "default"
2021-05-28 10:40:17.547 T:3137     INFO <general>: CAESinkALSA - Unable to open device "default" for playback
2021-05-28 10:40:17.547 T:3137    ERROR <general>: CAESinkALSA::Initialize - failed to initialize device "default"


On the other hand, in the working scenario I can see these entries when I start playing a movie:

Code:
2021-05-28 10:46:41.127 T:5482     INFO <general>: CActiveAESink::OpenSink - initialize sink
2021-05-28 10:46:41.327 T:5478    DEBUG <general>: Sink changed
2021-05-28 10:46:41.330 T:5482    DEBUG <general>: Skipped 2 duplicate messages..
2021-05-28 10:46:41.330 T:5482    DEBUG <general>: CActiveAESink::OpenSink - trying to open device ALSA:default
2021-05-28 10:46:41.331 T:5482     INFO <general>: CAESinkALSA::Initialize - Attempting to open device "default"
2021-05-28 10:46:41.344 T:5482     INFO <general>: CAESinkALSA::Initialize - Opened device "default"

Does anyone have any idea why this is happening?

Many thanks!
@ppianigiani

Maybe this is a race condition.

Have you ever tried not to let Kodi start automatically at boot time?

I can't understand this, it works fine for me (but I usually don't use it because I have extreme sound dropouts most of the time, even with a Raspberry Pi4), but my bluetooth speaker doesn't connect automatically after a (re)boot, I always have to do a sudo bluetoothctl connect <dev>

But the sound (both gui and video) is always present

Btw, a kernel update to 5.4.122 can't hurt either
@Nachteule

(29th May, 2021 05:03 AM)Nachteule Wrote: [ -> ]Btw, a kernel update to 5.4.122 can't hurt either

Thanks for your advice: first of all, I tried to upgrade to 5.4.122 and everything went fine, but now the bluetooth service is no longer running, so I can't enter the bluetoothctl cli to connect my BT HPs again...
I tried to restart the BT servicet, but I guess I did it the wrong way and it's not working yet...
Code:
xbian@xbian ~ $ sudo service bluetooth status
bluetooth stop/waiting
xbian@xbian ~ $
xbian@xbian ~ $ sudo service bluetooth start
bluetooth stop/pre-start, process 3878
xbian@xbian ~ $
xbian@xbian ~ $ sudo service bluetooth status
bluetooth stop/waiting
xbian@xbian ~ $
Any suggestion here?

(29th May, 2021 05:03 AM)Nachteule Wrote: [ -> ]Maybe this is a race condition.

Have you ever tried not to let Kodi start automatically at boot time?

Excellent point, I'll have a try, but unfortunately I don't know how to do it...
I searched for some instructions on the forums and found this: [SOLVED] How to disable XBMC launch at startup
...but it seems a pretty old thread and this method is not working, at least with my Xbian version...
Once more: any suggestion?

(29th May, 2021 05:03 AM)Nachteule Wrote: [ -> ]...but my bluetooth speaker doesn't connect automatically after a (re)boot, I always have to do a sudo bluetoothctl connect <dev>
I forgot to mention, but actually this is exactly the same solution I found and I've added to /etc/rc.local this command:
Code:
sudo -u xbian bluetoothctl connect <dev>

Many thanks!
(30th May, 2021 01:33 AM)ppianigiani Wrote: [ -> ]...I tried to upgrade to 5.4.122 and everything went fine, but now the bluetooth service is no longer running, so I can't enter the bluetoothctl cli to connect my BT HPs again...

A quick update: I still have bluetooth issues with 5.4.122, so I reverted back to 5.1.114 and luckily this time I was able to figure out how to stop Kodi from starting automatically at boot time (disabling autostart for "xbmc" service from xbian-config).
So, I've added to my /etc/rc.local the command to start Kodi just after the BT HPs get connected, like this:

Code:
sudo -u xbian  pulseaudio --start
sudo -u xbian bluetoothctl connect <dev>
service xbmc start

With this config, the audio on my BT HPs works fine both from GUI and from video/addons, so in the end it seems that Kodi MUST start after the BT device is already connected (and I guess this makes sense, after all...).
I'm afraid this solution is not very elegant and can't be applied for every case, but it does work for me, so I'd rather stick to it.

Any suggestion from anyone about the bluetooth service not running on 5.4.122?

Thanks!
It looks to me like now the rpi bluetooth device is no longer initialized and thus present

Please delete the file /var/log/upstart/rpi-bluetooth.log, restart and then post the file here

It should look like this:

Code:
/dev/serial1 still not there, waiting ...
using /dev/serial1@3000000
bcm43xx_init
Set Controller UART speed to 3000000 bit/s
Flash firmware /etc/firmware/brcm/BCM4345C0.hcd
Set BDADDR UART: aa:bb:cc:dd:ee:ff
Set Controller UART speed to 3000000 bit/s
Device setup complete
BDADDR need not be set for hci0

This is the output from my 3B+

Furthermore I have with my different configurations that the bluetooth daemon (bluetoothd) is not started correctly by the script /etc/init/bluetooth.conf or bluetooth is not in power up mode

However, this does not always occur with me, but with the 3B+ under Debian Buster. With Debian Bullseye and 4B this is always ok

Anyway, I made a new script, you could also try this as a test

cat /etc/init/bluetooth.conf
Code:
description "bluetooth"
author      "mkreisl mkreisl@xbian.org"

start on (started rpi-bluetooth or started imx-bluetooth)
stop on runlevel [06]

env DAEMON=/usr/sbin/bluetoothd
env HCIATTACH=/usr/bin/hciattach

env HID2HCI_ENABLED=1
env HID2HCI_UNDO=1

env SDPTOOL=/usr/bin/sdptool

# If you want to be ignore error of "org.freedesktop.hostname1",
# please enable NOPLUGIN_OPTION.
# NOPLUGIN_OPTION="--noplugin=hostname"
env NOPLUGIN_OPTION=""

script
    [ -f /etc/default/bluetooth ] && . /etc/default/bluetooth
    [ -f /etc/default/rcS ] && . /etc/default/rcS

    [ "$BLUETOOTH_ENABLED" = 1 ] || { stop; exit 0; }

    SSD_OPTIONS="--oknodo --quiet --exec $DAEMON -- $NOPLUGIN_OPTION"
    start-stop-daemon --start $SSD_OPTIONS
end script

post-start script
    [ -f /etc/default/bluetooth ] && . /etc/default/bluetooth
    [ -f /etc/default/rcS ] && . /etc/default/rcS

    # FIXME: this function is possibly a no-op
    run_sdptool()
    {
        # declaring IFS local in this function, removes the need to
        # save/restore it
        local IFS o

        test -x $SDPTOOL || return 1

        # FIXME: where does SDPTOOL_OPTIONS come from?
        if ! test -z "$SDPTOOL_OPTIONS" ; then
            IFS=";"
            for o in $SDPTOOL_OPTIONS ; do
                #echo "execing $SDPTOOL $o"
                IFS=" "
                if [ "$VERBOSE" != no ]; then
                    $SDPTOOL $o
                else
                    $SDPTOOL $o >/dev/null 2>&1
                fi
            done
        fi
    }

    run_sdptool || :

    if test "$HID2HCI_ENABLED" = 1; then
        echo "switching to HID/HCI no longer done here, see /usr/share/doc/bluez/NEWS.Debian.gz" || :
    fi

    bluetoothctl power on
end script

post-stop script
    [ -f /etc/default/bluetooth ] && . /etc/default/bluetooth
    [ -f /etc/default/rcS ] && . /etc/default/rcS

    if test "$HID2HCI_UNDO" = 1; then
        echo "switching to HID/HCI no longer done here, see /usr/share/doc/bluez/NEWS.Debian.gz" || :
    fi

end script

With this new script you should see in the file /var/log/upstart/bluetooth.log the following

Code:
Changing power on succeeded
[CHG] Controller AA:BB:CC:DD:EE:FF Powered: yes
(30th May, 2021 10:32 PM)Nachteule Wrote: [ -> ]Please delete the file /var/log/upstart/rpi-bluetooth.log, restart and then post the file here

Here's the content of my /var/log/upstart/rpi-bluetooth.log when running version 5.4.122, after deleting the log file and rebooting:

Code:
/dev/serial1 still not there, waiting ...
/dev/serial1 still not there, waiting ...
/dev/serial1 still not there, waiting ...
/dev/serial1 still not there, waiting ...
/dev/serial1 still not there, waiting ...
rpi-bluetooth stop/pre-start, process 2531

As a comparison, here's the same /var/log/upstart/rpi-bluetooth.log file when running version 5.1.114 (please, notice I'm swapping SD cards on the same RPi3B+ board to test 5.4.114 and 5.4.122 back and forth, so I'm pretty sure the HW is working fine):

Code:
using ttyAMA0@921600
bcm43xx_init
Initialization timed out.
using ttyAMA0@921600
bcm43xx_init
Set Controller UART speed to 921600 bit/s
Flash firmware /etc/firmware/BCM4345C0.hcd
Set Controller UART speed to 921600 bit/s
Device setup complete


(30th May, 2021 10:32 PM)Nachteule Wrote: [ -> ]Anyway, I made a new script, you could also try this as a test
I also had a try to your script, but unfortunately it made no difference, here's the /var/log/upstart/rpi-bluetooth.log file (when running on 5.4.122 with the new BT script):

Code:
/dev/serial1 still not there, waiting ...
/dev/serial1 still not there, waiting ...
/dev/serial1 still not there, waiting ...
/dev/serial1 still not there, waiting ...
/dev/serial1 still not there, waiting ...
rpi-bluetooth stop/pre-start, process 2445
Pages: 1 2 3 4 5 6
Reference URL's