The newest bluetooth thread (MX4 and OPO)
I have both an OPO and a an MX4. I've been using the MX4 with 15.04 and it's been working with bluetooth and all.
For kicks, I tested the latest 16.04 dev on the OPO because of anbox. Pretty good, only problem is google play services, but that'll probably be solved.
Thing is though, that I use bluetooth a lot in my car, and the OPO doesn't work with bluetooth - at least not in my car. I thought - well I can just install 16.04 on the MX4, and with a couple of tricks, also make anbox run on that. That worked like a charm, but now bluetooth has stopped working on the MX4 too.
It behaves the same way as the OPO, so the problem is not something device/firmware specific.
Any tricks/tips or anything? I would hate to go back to 15.04 - especially now with 16.04 being better in many other ways....
Moved to Support because this topic fits better here than in OS (that's for "Discussions on development of Ubuntu Touch")
@grisen https://ubports.com/blog/ubports-blog-1/post/ubuntu-touch-q-a-36-171 have a read through the bluetooth section in the blog notes for a good explanation of things. There are a few posts on car kits etc in the support section to have a look at.
The very basic is bluetooth needs a lot of dev time. Time that as mostly volunteers the dev here need to allocate very carefully but it is being done.
It might even be a general issue with bluetooth.
There is also a related issue on Github.
@lakotaubp You need:
- All different kinds of devices
- Spend lot of your time with the laptop in the car debugging the car kit, since you cant bring it into the living room
- Optional: Own a few cars
Thats the truth, how developers can fix all the million combinations of car kits and BT hardware on devices? this one really makes me idealess ^^
This seems like general issue to me to. Dialer app regression maybe ?
Changes in More Detail
BlueZ 5 support (A2DP only)
First some background: The BlueZ project decided to redesign their client interface. They also decided to drop support for the old client interface. BlueZ 4 has the old interface and BlueZ 5 has the new interface. The decision to drop support for the old interface in BlueZ 5 meant that all applications, including PulseAudio, that used to work with BlueZ 4 didn't work with BlueZ 5.
The support for BlueZ 5 has been gradually added in various applications, and this is the first PulseAudio version that supports BlueZ 5. This means that everything is great, right? Not so. **The BlueZ project also decided to drop support for the HSP and HFP profiles, which were the profiles responsible for handling telephony audio. If you have a headset, its microphone won't work with BlueZ 5, because the microphone is only supported by the HSP and HFP profiles.
There are distributions that have migrated to BlueZ 5 without providing users the alternative of staying with BlueZ 4. Some of those distributions probably made the transition without understanding the consequences - they now have a serious regression in functionality, because their users' Bluetooth headsets have stopped working (well, the headsets can still be used for listening to music, but they're useless for VoIP applications).
GNOME made also a decision, possibly misinformed one, to drop support for BlueZ 4 in their last release, which means that upgrading to the current GNOME version (3.10) has one of two problems depending on the BlueZ version in the system: with BlueZ 4, the GNOME UI for managing Bluetooth won't work, and with BlueZ 5 the headset audio functionality will be crippled.
So what's the way forward with getting the HSP and HFP profiles work with BlueZ 5? There is partial support for those in oFono (a telephony daemon), which will hopefully be completed soon, and the next PulseAudio release will then hopefully support HSP/HFP through oFono. This pulls in a telephony stack as a dependency for using your Bluetooth headset, which might be considered overkill. This issue is yet to be resolved with the BlueZ developers.**
Now, the technical details of the BlueZ 5 support in PulseAudio: there are now separate modules for BlueZ 4 and BlueZ 5: module-bluez4-discover and module-bluez5-discover. The old module-bluetooth-discover still exists and is used in the default configuration. The role of module-bluetooth-discover is now to act as an abstraction layer: it will load module-bluez4-discover and/or module-bluez5-discover based on what's present in the system. This means that the migration to BlueZ 5 can be done without changing the PulseAudio configuration.
WTF ??? Is this the case here ?
My current version of bluez:
bluez/xenial,now 5.42+ubports armhf [installed,automatic]
@mprotic Finally some light into the problems of many people maybe. We will investigate...
xenial (16.04LTS) (admin): Bluetooth tools and daemons
5.37-0ubuntu5.1 [security]: amd64 i386
5.37-0ubuntu5 [ports]: arm64 armhf powerpc ppc64el s390x
xenial (16.04LTS) (sound): PulseAudio sound server
1:8.0-0ubuntu3: amd64 arm64 armhf i386 powerpc ppc64el s390x
The correct release notes of actual Xenial PulseAudio are 8.0. We should are track and find from v5 pulseaudio to actual xenial to try to find if make something new to support all this types of devices.
UPDATE: In this release yet make some commits for this issue: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/6.0/
UPDATE 2: Talk about oFono 1.13 and apply this patch for this function: https://lists.freedesktop.org/archives/pulseaudio-discuss/2015-February/023102.html
Same situation to the actual BlueZ version for xenial.
And finally will see if oFono support or can handle somethig whit this versions.
What do you think?
Yeah, this does seem to be patched:
Though, bug is still open
https://wiki.archlinux.org/index.php/bluetooth#Pairing => bluetoothctl can be a very nice tool for debugging BT problems. You can pair/unpair and interrogate devices etc. I would give it a try whenever there are BT problems.