Bluetooth Handsfree Bounty

[Kevin Kofler]

Note that Phosh (by default – it supports both) and Plasma Mobile (since 21.12) both use ModemManager, not ofono.

[JohnA]

OK, after some digging.
Pipewire seems to have the full featured bluetooth device. It is even transmitting the state of charge to the car / other device.
Other pulseaudio variants do not seem to have the full bluetooth device, or don't seem to be able to connect to devices without some help or configuration adjustment. I've tried pushing and prodding various versions of pulseaudio - but it does not seem I can get everything going at once that we need. It may be some subtle configuration issue, but for the present I've moved on.
However - at least from config files - pipewire suggests it can either connect to ofono or run some sort of "native" interface, which may be something akin to the pulseaudio hfp one mentioned.
However, equally, there do not seem to be any "recipies" for how you get a pipewire bluetooth audio gateway going - it may be that the default configuration in the package does not enable it, but with some adjustment, it could be possible to get it doing the hfp type pad interfacing.
So, I'm delving into the depths of pipewire at the moment.

[conifera]

So, I'm delving into the depths of pipewire at the moment.

I'm encouraged and will be waiting patiently and checking periodically. I understand it may take a while.

I'm guessing there are a lot of people who would like to see this but who haven't spoken up.

[Zebulon Walton]

I'm encouraged and will be waiting patiently and checking periodically.  I understand it may take a while.

I'm guessing there are a lot of people who would like to see this but who haven't spoken up.

It would fill a nice gap in functionality, though I've done all right (albeit somewhat clumsily) using a wired headset. If bluetooth audio were working that would probably be a good enough reason for me to try pipewire again, maybe even move to trixie if needed for that to work properly. (When I tried pipewire on bookworm the volume controls started working during calls but audio routing got messed up pretty badly so I went back to pulseaudio.)

[JohnA]

OK, so I've managed to get the car to tell the phone what number to call over the hfp bluetooth link, I managed to figure out how to configure wireplumber to access the local pinephone modem. While I'm sure the pulseaudio variant can do this, pipewire / wireplumber can get the interface to work.
However, since the last phone update, my phone is now behaving erratically - it does not automatically reconfigure the phone to "Voice Call" when a voice call comes in, which my script relied on. Its actually pretty annoying for general use, too.
I could prompt a "manual audio transfer", which might work, but also sorta defeats the purpose. Ideally, either me poking around or an update will fix the voice call audio configuration update issue.
Investigations continue.

[JohnA]

OK, some progress. I was wrong thinking the update caused the problem.
In fact, when you set pipewire to connect to the local modem, the phone goes into "Audio Gateway" mode, and becomes unresponsive, not telling you about phonecalls and not being able to change the audio config via the sound menu. It was a coincidence the phone did an update at just the time I started to notice the problem, but there you go.
You cannot see a change of sound card state indicating there is an incoming call. However, there is a "pause" you can pick up on, and I've set my script to key on that.
The problem is, my script cannot see the call has ended - there's no change in the sound card to indicate that. So, you have to manually turn of the call at least at the interface and maybe at the phone, and then run the reset script so the phone is ready for the next call.
It may be possible to answer an incoming call from the car "answer" button, I've not checked that.
However, I do have an interface to the car that tell you the signal strength and battery state of charge, and even the name of the carrier, where you can type in you number to the car interface, and the phone will call, answer, and route the call to the car speaker and car mic. At least, that part happens automatically. The car is, however, confused about past calls, these are not downloaded into the car interface, you need to type in the actual number.
It may be that there is some way of programming/configuring pipewire / wireplumber to automatically change configuration and let other things around know about the change. But, in the meantime, I hope to tap into d-bus to find out what the call is doing. That might just be dbus-monitor with a select statement, which should have a minimum overhead, or might well be using the perl libraries. d-bus is a struggle, but it is slowly making more sense. Pipewire is pretty confusing, too.
Anyway, it works but it is at the stage of "stand on one leg, bend the other foot to rest on your knee and poke your tongue out while pressing a button".

[walter1950]

OK, some progress. I was wrong thinking the update caused the problem.
In fact, when you set pipewire to connect to the local modem, the phone goes into "Audio Gateway" mode, and becomes unresponsive, not telling you about phonecalls and not being able to change the audio config via the sound menu. It was a coincidence the phone did an update at just the time I started to notice the problem, but there you go.
You cannot see a change of sound card state indicating there is an incoming call. However, there is a "pause" you can pick up on, and I've set my script to key on that.
The problem is, my script cannot see the call has ended - there's no change in the sound card to indicate that. So, you have to manually turn of the call at least at the interface and maybe at the phone, and then run the reset script so the phone is ready for the next call.
It may be possible to answer an incoming call from the car "answer" button, I've not checked that.
However, I do have an interface to the car that tell you the signal strength and battery state of charge, and even the name of the carrier, where you can type in you number to the car interface, and the phone will call, answer, and route the call to the car speaker and car mic. At least, that part happens automatically. The car is, however, confused about past calls, these are not downloaded into the car interface, you need to type in the actual number.
It may be that there is some way of programming/configuring pipewire / wireplumber to automatically change configuration and let other things around know about the change. But, in the meantime, I hope to tap into d-bus to find out what the call is doing. That might just be dbus-monitor with a select statement, which should have a minimum overhead, or might well be using the perl libraries. d-bus is a struggle, but it is slowly making more sense. Pipewire is pretty confusing, too.
Anyway, it works but it is at the stage of "stand on one leg, bend the other foot to rest on your knee and poke your tongue out while pressing a button".

Well done!

I increase my Donation Part https://forum.pine64.org/showthread.php?...#pid121187 to 300 Euro :-)

Ciao
Walter

BTW: where are you located?

[JohnA]

OK, some progress. I was wrong thinking the update caused the problem.
In fact, when you set pipewire to connect to the local modem, the phone goes into "Audio Gateway" mode, and becomes unresponsive, not telling you about phonecalls and not being able to change the audio config via the sound menu. It was a coincidence the phone did an update at just the time I started to notice the problem, but there you go.
You cannot see a change of sound card state indicating there is an incoming call. However, there is a "pause" you can pick up on, and I've set my script to key on that.
The problem is, my script cannot see the call has ended - there's no change in the sound card to indicate that. So, you have to manually turn of the call at least at the interface and maybe at the phone, and then run the reset script so the phone is ready for the next call.
It may be possible to answer an incoming call from the car "answer" button, I've not checked that.
However, I do have an interface to the car that tell you the signal strength and battery state of charge, and even the name of the carrier, where you can type in you number to the car interface, and the phone will call, answer, and route the call to the car speaker and car mic. At least, that part happens automatically. The car is, however, confused about past calls, these are not downloaded into the car interface, you need to type in the actual number.
It may be that there is some way of programming/configuring pipewire / wireplumber to automatically change configuration and let other things around know about the change. But, in the meantime, I hope to tap into d-bus to find out what the call is doing. That might just be dbus-monitor with a select statement, which should have a minimum overhead, or might well be using the perl libraries. d-bus is a struggle, but it is slowly making more sense. Pipewire is pretty confusing, too.
Anyway, it works but it is at the stage of "stand on one leg, bend the other foot to rest on your knee and poke your tongue out while pressing a button".

Well done!

I increase my Donation Part https://forum.pine64.org/showthread.php?...#pid121187 to 300 Euro :-)

Ciao
Walter

BTW: where are you located?

Sydney, Australia.

[JohnA]

OK, more notes.
I've been trying to get the ofonod program to work, as I'm hoping it will have the full comms with the car interface, including the telephone book, answering calls from the car, and so on.
I had originally hoped to just tune the config files, but it seems more difficult. There's confusion between the gobi, quectelqmi and quectel plugins & the atmodem and quectelqmi drivers. It seems that I need to make a quectelppp plugin which farms out the needed tasks to the quectelqmi and atmodem drivers, as it seems the ppp has divided up the responsibilities between a qmi interface for power, signal strength etc. and the atmodem for actual modem dialup and similar commands.
Of course I could be wrong ... maybe a single "tweak" will get it all going, but that's my current path.
At least I'm now much more familiar with how dbus and udev work.
Please let me know if there has been progress elsewhere!
Cheers, John.

[Kevin Kofler]

I've been trying to get the ofonod program to work,

I still do not understand why all this focus on ofono, considering that:

Note that Phosh (by default – it supports both) and Plasma Mobile (since 21.12) both use ModemManager, not ofono.