[PROBLEM] Issue with Blutooth in 4.1

[Tim Curtis]

Hi @badbat75,

I extracted the Bluetooth recipe from your custom Builder at https://github.com/badbat75/rpi_moode_build

Am I correct in understanding that this bluetooth build resolved your connection issues?

Code:

# Remove current bluez installation
sudo apt-get -y remove bluez libbluetooth-dev libbluetooth3

# Compile bluez
wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.49.tar.xz
#cp ./rel-stretch/other/bluetooth/bluez-5.49.tar.xz ./
tar xvf bluez-5.49.tar.xz
cd bluez-5.49
./configure \
   --prefix=/usr \
   --libdir=/usr/lib/arm-linux-gnueabihf \
   --sysconfdir=/etc \
   --localstatedir=/var \
   --enable-library \
   --enable-manpages \
   --enable-deprecated \
   --disable-cups \
   --disable-hid \
   --disable-hog \
   --disable-network \
   --disable-obex
make
sudo make install
cd ~
rm -rf ./bluez-5.49*

# Install pi bluetooth
git clone https://github.com/RPi-Distro/pi-bluetooth
sudo cp pi-bluetooth/usr/bin/btuart /usr/bin/
sudo cp pi-bluetooth/debian/pi-bluetooth.hciuart.service /etc/systemd/system/hciuart.service
sudo systemctl daemon-reload
rm -rf pi-bluetooth

# Compile bluez-alsa
cd /tmp
git clone -b v1.2.0 --single-branch https://github.com/Arkq/bluez-alsa.git
cd bluez-alsa
autoreconf --install
mkdir build
cd build
../configure --disable-hcitop --with-alsaplugindir=/usr/lib/arm-linux-gnueabihf/alsa-lib
make
sudo make install
cd ~
rm -rf /tmp/bluez-alsa

# Services are started by moOde Worker so lets disable them here
sudo systemctl daemon-reload
sudo systemctl disable bluetooth.service
sudo systemctl disable hciuart.service

# Finish up
sudo mkdir -p /var/run/bluealsa
sudo sync

-Tim

[badbat75]

Hi @badbat75,

I extracted the Bluetooth recipe from your custom Builder at https://github.com/badbat75/rpi_moode_build

Am I correct in understanding that this bluetooth build resolved your connection issues?

Code:

# Remove current bluez installation
sudo apt-get -y remove bluez libbluetooth-dev libbluetooth3

# Compile bluez
wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.49.tar.xz
#cp ./rel-stretch/other/bluetooth/bluez-5.49.tar.xz ./
tar xvf bluez-5.49.tar.xz
cd bluez-5.49
./configure \
   --prefix=/usr \
   --libdir=/usr/lib/arm-linux-gnueabihf \
   --sysconfdir=/etc \
   --localstatedir=/var \
   --enable-library \
   --enable-manpages \
   --enable-deprecated \
   --disable-cups \
   --disable-hid \
   --disable-hog \
   --disable-network \
   --disable-obex
make
sudo make install
cd ~
rm -rf ./bluez-5.49*

# Install pi bluetooth
git clone https://github.com/RPi-Distro/pi-bluetooth
sudo cp pi-bluetooth/usr/bin/btuart /usr/bin/
sudo cp pi-bluetooth/debian/pi-bluetooth.hciuart.service /etc/systemd/system/hciuart.service
sudo systemctl daemon-reload
rm -rf pi-bluetooth

# Compile bluez-alsa
cd /tmp
git clone -b v1.2.0 --single-branch https://github.com/Arkq/bluez-alsa.git
cd bluez-alsa
autoreconf --install
mkdir build
cd build
../configure --disable-hcitop --with-alsaplugindir=/usr/lib/arm-linux-gnueabihf/alsa-lib
make
sudo make install
cd ~
rm -rf /tmp/bluez-alsa

# Services are started by moOde Worker so lets disable them here
sudo systemctl daemon-reload
sudo systemctl disable bluetooth.service
sudo systemctl disable hciuart.service

# Finish up
sudo mkdir -p /var/run/bluealsa
sudo sync

-Tim

Yes, if you don't want to change your build environment created by the official moode builder, the only thing I made to solve the problem is to specify the tag of the bluezalsa repository (-b 1.2.0). All the other things are little tuning of what is already working, I mean I tested everything with the recipe you attached to the moode package.
Those are my little changes in the build procedures:

• First of all, I like to have a clean environment, so I removed the bluez and all related libraries from raspbian, then I built the bluez disabling all the modules not needed (the disable-obex is not working really, because the configure script leaves indeed the build and the installation of the obexd server and all related tools). I want to test in the next days if the enable-thread configuration parameter is really needed and if there are performance and RAM benefits. (In the official raspbian build the threads are enabled)
  
• Unfortunately the removal of the bluez packages remove also the pi-bluetooth (specific for bluetooth device integrated in the rPi3) package because dependant, so the need to get the sources and install like others (not tested yet, I will try in my rPi3 build device)
  
• At the end the bluezalsa module (nothing changed here).
  

Anyway Moode is the only HiFi project I trust because it is simple to manage and you can really customize what you wants.

[badbat75]

Hi,

Yes, please create a dedicated thread so we can understand your nice approach to Building moOde :-)

-Tim

Of course I will.

[Tim Curtis]

Hi @badbat75,

I extracted the Bluetooth recipe from your custom Builder at https://github.com/badbat75/rpi_moode_build

Am I correct in understanding that this bluetooth build resolved your connection issues?

Code:

# Remove current bluez installation
sudo apt-get -y remove bluez libbluetooth-dev libbluetooth3

# Compile bluez
wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.49.tar.xz
#cp ./rel-stretch/other/bluetooth/bluez-5.49.tar.xz ./
tar xvf bluez-5.49.tar.xz
cd bluez-5.49
./configure \
   --prefix=/usr \
   --libdir=/usr/lib/arm-linux-gnueabihf \
   --sysconfdir=/etc \
   --localstatedir=/var \
   --enable-library \
   --enable-manpages \
   --enable-deprecated \
   --disable-cups \
   --disable-hid \
   --disable-hog \
   --disable-network \
   --disable-obex
make
sudo make install
cd ~
rm -rf ./bluez-5.49*

# Install pi bluetooth
git clone https://github.com/RPi-Distro/pi-bluetooth
sudo cp pi-bluetooth/usr/bin/btuart /usr/bin/
sudo cp pi-bluetooth/debian/pi-bluetooth.hciuart.service /etc/systemd/system/hciuart.service
sudo systemctl daemon-reload
rm -rf pi-bluetooth

# Compile bluez-alsa
cd /tmp
git clone -b v1.2.0 --single-branch https://github.com/Arkq/bluez-alsa.git
cd bluez-alsa
autoreconf --install
mkdir build
cd build
../configure --disable-hcitop --with-alsaplugindir=/usr/lib/arm-linux-gnueabihf/alsa-lib
make
sudo make install
cd ~
rm -rf /tmp/bluez-alsa

# Services are started by moOde Worker so lets disable them here
sudo systemctl daemon-reload
sudo systemctl disable bluetooth.service
sudo systemctl disable hciuart.service

# Finish up
sudo mkdir -p /var/run/bluealsa
sudo sync

-Tim

Yes, if you don't want to change your build environment created by the official moode builder, the only thing I made to solve the problem is to specify the tag of the bluezalsa repository (-b 1.2.0). All the other things are little tuning of what is already working, I mean I tested everything with the recipe you attached to the moode package.
Those are my little changes in the build procedures:

• First of all, I like to have a clean environment, so I removed the bluez and all related libraries from raspbian, then I built the bluez disabling all the modules not needed (the disable-obex is not working really, because the configure script leaves indeed the build and the installation of the obexd server and all related tools). I want to test in the next days if the enable-thread configuration parameter is really needed and if there are performance and RAM benefits. (In the official raspbian build the threads are enabled)
  
• Unfortunately the removal of the bluez packages remove also the pi-bluetooth (specific for bluetooth device integrated in the rPi3) package because dependant, so the need to get the sources and install like others (not tested yet, I will try in my rPi3 build device)
  
• At the end the bluezalsa module (nothing changed here).
  

Anyway Moode is the only HiFi project I trust because it is simple to manage and you can really customize what you wants.

Hi,

I'm seeing same version number from master branch, at least from the last time I ran a build which was at moOde 4.1 release.
pi@moode:~ $ bluealsa -V
1.2.0

Is the issue that master branch has changes not in -b 1.2.0 ?

-Tim

[badbat75]

Hi @badbat75,

I extracted the Bluetooth recipe from your custom Builder at https://github.com/badbat75/rpi_moode_build

Am I correct in understanding that this bluetooth build resolved your connection issues?

Code:

# Remove current bluez installation
sudo apt-get -y remove bluez libbluetooth-dev libbluetooth3

# Compile bluez
wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.49.tar.xz
#cp ./rel-stretch/other/bluetooth/bluez-5.49.tar.xz ./
tar xvf bluez-5.49.tar.xz
cd bluez-5.49
./configure \
   --prefix=/usr \
   --libdir=/usr/lib/arm-linux-gnueabihf \
   --sysconfdir=/etc \
   --localstatedir=/var \
   --enable-library \
   --enable-manpages \
   --enable-deprecated \
   --disable-cups \
   --disable-hid \
   --disable-hog \
   --disable-network \
   --disable-obex
make
sudo make install
cd ~
rm -rf ./bluez-5.49*

# Install pi bluetooth
git clone https://github.com/RPi-Distro/pi-bluetooth
sudo cp pi-bluetooth/usr/bin/btuart /usr/bin/
sudo cp pi-bluetooth/debian/pi-bluetooth.hciuart.service /etc/systemd/system/hciuart.service
sudo systemctl daemon-reload
rm -rf pi-bluetooth

# Compile bluez-alsa
cd /tmp
git clone -b v1.2.0 --single-branch https://github.com/Arkq/bluez-alsa.git
cd bluez-alsa
autoreconf --install
mkdir build
cd build
../configure --disable-hcitop --with-alsaplugindir=/usr/lib/arm-linux-gnueabihf/alsa-lib
make
sudo make install
cd ~
rm -rf /tmp/bluez-alsa

# Services are started by moOde Worker so lets disable them here
sudo systemctl daemon-reload
sudo systemctl disable bluetooth.service
sudo systemctl disable hciuart.service

# Finish up
sudo mkdir -p /var/run/bluealsa
sudo sync

-Tim

Yes, if you don't want to change your build environment created by the official moode builder, the only thing I made to solve the problem is to specify the tag of the bluezalsa repository (-b 1.2.0). All the other things are little tuning of what is already working, I mean I tested everything with the recipe you attached to the moode package.
Those are my little changes in the build procedures:

• First of all, I like to have a clean environment, so I removed the bluez and all related libraries from raspbian, then I built the bluez disabling all the modules not needed (the disable-obex is not working really, because the configure script leaves indeed the build and the installation of the obexd server and all related tools). I want to test in the next days if the enable-thread configuration parameter is really needed and if there are performance and RAM benefits. (In the official raspbian build the threads are enabled)
  
• Unfortunately the removal of the bluez packages remove also the pi-bluetooth (specific for bluetooth device integrated in the rPi3) package because dependant, so the need to get the sources and install like others (not tested yet, I will try in my rPi3 build device)
  
• At the end the bluezalsa module (nothing changed here).
  

Anyway Moode is the only HiFi project I trust because it is simple to manage and you can really customize what you wants.

Hi,

I'm seeing same version number from master branch, at least from the last time I ran a build which was at moOde 4.1 release.
pi@moode:~ $ bluealsa -V
1.2.0

Is the issue that master branch has changes not in -b 1.2.0 ?

-Tim

There are a lot of changes, the code was tagged one year ago.  Meanwhile there were a lot of commits, but they left the version to 1.2.0, that's the problem IMHO...

[Tim Curtis]

Well, that explains it. Thanks so much for providing such great info :-)

-Tim

[TheOldPresbyope]

Hi guys,
hello to everyone on this new forum.
I will tell you my story on bluetooth stack.
By default I was not able to pair any device iOS, Android or Windows devices.
On iOS I could pair but I couldn't connect, when I tried it failed and then it removed the devices.
On Windows devices I could connect but it disconnected after a while.
On Android it refuses to pair
So I did some tries starting the bluetooth stack manually and everything works flawlessy.
When I started the bluealsa service everything stops working.
So I tried to download version 1.2.0 instead of the master and everything started working.
Those are the step I used to build this version:
...

@badbat75
Haven't seen anyone else report this level of BT difficulty with r4.1. Tim's been using his iOS devices. I've never had a problem getting my Android (Marshmallow, Nougat, Oreo) devices to pair. I have had an issue with my Android devices then connecting with moOde but not streaming audio to it until I've disconnected and connected again. Not nearly as severe a problem as you report.
Are you running vanilla r4.1?
What was the basis for your decision to revert to a year-old release of bluez-alsa?
Inquiring minds want to know
Regards,
Kent

Hi Kent,
yes it was vanilla r4.1.
When I saw the problems raised during the startup of the bluezalsa service I tried to understand where was the problem, but I was not able to find it.
With moode r4.0 everything was working fine, so I tried first the standard bluez package provided with raspbian (same results), then I tried the bluez 5.49 and the latest stable version of bluezalsa (1.2.0) and it worked!!! I also saw that master branch of bluezalsa is very lively: the last change is 7 hours ago now in the src folder (for example) so probably the package change at every build and probably if I generate a new build now perhaps could work...
Stability is the main reason I decided to stay stuck to 1.2.0.
Let me know what you think.

@badbat75

I think you are very meticulous in your programming work and that's a good thing

I hadn't twigged to the bluez-alsa release number issue. I suppose one could dig through to find the most recent stable commit but that's a lot of work.

I'm taking a shortcut by reverting an existing r41 to last year's bluezalsa v1.2.0 release to see if this solves my Android BT connection issue. Of course I have to try your custom builder too but that's a project for when I have a block of time available later.

***UPDATE*** 
Having reverted to the v1.2.0 release, it seems like my Android Nexus 6P phone (Oreo) is establishing a working connection with moOde r4.1 on the first try. It seems like my Android Nexus 9 tablet (Nougat) is a little more fiddly but it still established a working connection without the rigmarole I was going through before.
***

Back when I had only early-generation RPis I sped up my moOde build-cycle using distcc to distribute compilations to cross-compilers on fast x86 hosts. Haven't done it since the release of the RPi3B. Building moOde on it with the Automated moOde OS Builder is fast enough to not want to bother.

Regards,
Kent

[Tim Curtis]

Hi Kent,

Nice to hear that revert to -b v1.2.0 may be the solution :-)

Did you just recompile over top of existing blues-alsa using procedure below from @badbat75  ? If yes then I'll do same on my end and begin testing with my IOS and Anker devices.

Code:

# Compile bluez-alsa
cd /tmp
git clone -b v1.2.0 --single-branch https://github.com/Arkq/bluez-alsa.git
cd bluez-alsa
autoreconf --install
mkdir build
cd build
../configure --disable-hcitop --with-alsaplugindir=/usr/lib/arm-linux-gnueabihf/alsa-lib
make
sudo make install
cd ~
rm -rf /tmp/bluez-alsa

-Tim

[TheOldPresbyope]

Hi Kent,

Nice to hear that revert to -b v1.2.0 may be the solution :-)

Did you just recompile over top of existing blues-alsa using procedure below from @badbat75  ? If yes then I'll do same on my end and begin testing with my IOS and Anker devices.

Code:

# Compile bluez-alsa
cd /tmp
git clone -b v1.2.0 --single-branch https://github.com/Arkq/bluez-alsa.git
cd bluez-alsa
autoreconf --install
mkdir build
cd build
../configure --disable-hcitop --with-alsaplugindir=/usr/lib/arm-linux-gnueabihf/alsa-lib
make
sudo make install
cd ~
rm -rf /tmp/bluez-alsa

-Tim

Yes, but I have to say I still have reservations about whether this is *the* solution. It's been so easy to chase down blind alleys with BT, not that I'm telling you anything new. I struggle to bring both moOde and my Android devices to a pristine state before each test and I'm not sure I'm succeeding.

I found a comment in the bluez-alsa issues log which may suggest an explanation for my problem:

A2DP is muted when HFP profile is activated

HFP is the Bluetooth Hands-Free Profile. It looks there have been HFP-related commits to bluez-alsa over the last two years but important ones (such as "HFP-HF service level connection procedure") came after the v1.2.0 release. Why I could get audio by disconnecting and reconnecting is still a mystery.

If the v1.2.0 release of bluez-alsa works well enough in testing, fine, otherwise we may need to search for the latest commit to bluez-alsa which does.

Regards,
Kent

[badbat75]

If the v1.2.0 release of bluez-alsa works well enough in testing, fine, otherwise we may need to search for the latest commit to bluez-alsa which does.

I totally agree with you!!!
And I'm glad to know that my help could be useful.