For over two years, there have been many scattered posts from people wanting
to be able to use their phones to make and receive calls using hands-free
bluetooth devices. This has been standard with android phones for well over
10 years.
From what I can see with pipewire and wireplumber, and from what others have
said, it is just a matter of creating the proper audio profile
(pipewire/wireplumber configuration) to route the audio between bluetooth and
the modem. If there was proper documentation of the relevant systems I would
figure it out myself and post the solution here.
There are certainly people who understand pipewire/wireplumber well enough
that it would be fairly straightforward for them to solve this problem if
they thought it worth the effort.
I will give $50 to the first person or project (Mobian for example) who,
before June 1, 2024, will come up with a solution compatible with hfp 1.5 and
later, and make it publicly available in a way that the common pinephone
(original) user can make use of it. This could be somthing like an
installable package or upgrade to a package, a script to make changes or, if
it came with complete step-by-step instructions, as a set of edits to
configuration files.
I realize $50 by itself might not be enough motivation so I would ask those
who also need this to at least register their desire for it by taking the
time to add a post to this thread, and for those who can, by also offering
additional money.
Maybe someone with the knowledge just needs to know that people need this.
01-02-2024, 12:31 AM
(This post was last modified: 01-02-2024, 12:33 AM by 33YN2.)
(12-28-2023, 05:37 PM)conifera Wrote: For over two years, there have been many scattered posts from people wanting
to be able to use their phones to make and receive calls using hands-free
bluetooth devices. This has been standard with android phones for well over
10 years.
From what I can see with pipewire and wireplumber, and from what others have
said, it is just a matter of creating the proper audio profile
(pipewire/wireplumber configuration) to route the audio between bluetooth and
the modem. If there was proper documentation of the relevant systems I would
figure it out myself and post the solution here.
There are certainly people who understand pipewire/wireplumber well enough
that it would be fairly straightforward for them to solve this problem if
they thought it worth the effort.
I will give $50 to the first person or project (Mobian for example) who,
before June 1, 2024, will come up with a solution compatible with hfp 1.5 and
later, and make it publicly available in a way that the common pinephone
(original) user can make use of it. This could be somthing like an
installable package or upgrade to a package, a script to make changes or, if
it came with complete step-by-step instructions, as a set of edits to
configuration files.
I realize $50 by itself might not be enough motivation so I would ask those
who also need this to at least register their desire for it by taking the
time to add a post to this thread, and for those who can, by also offering
additional money.
Maybe someone with the knowledge just needs to know that people need I recall a website that allowed people to put in money and when a developer completed their request they would check off on it and the developer gets the money. Forgot what its called but it would be good in this case.
I'd be willing to put $200 toward this bounty.
(01-02-2024, 12:31 AM)33YN2 Wrote: (12-28-2023, 05:37 PM)conifera Wrote: For over two years, there have been many scattered posts from people wanting
to be able to use their phones to make and receive calls using hands-free
bluetooth devices. This has been standard with android phones for well over
10 years.
...
I realize $50 by itself might not be enough motivation so I would ask those
who also need this to at least register their desire for it by taking the
time to add a post to this thread, and for those who can, by also offering
additional money.
Maybe someone with the knowledge just needs to know that people need I recall a website that allowed people to put in money and when a developer completed their request they would check off on it and the developer gets the money. Forgot what its called but it would be good in this case.
I'd be willing to put $200 toward this bounty.
Me to, 200 Euro!
Ciao
Walter
(01-02-2024, 07:18 AM)walter1950 Wrote: (01-02-2024, 12:31 AM)33YN2 Wrote: (12-28-2023, 05:37 PM)conifera Wrote: ...
I realize $50 by itself might not be enough motivation so I would ask those
who also need this to at least register their desire for it by taking the
time to add a post to this thread, and for those who can, by also offering
additional money.
Maybe someone with the knowledge just needs to know that people need I recall a website that allowed people to put in money and when a developer completed their request they would check off on it and the developer gets the money. Forgot what its called but it would be good in this case.
I'd be willing to put $200 toward this bounty.
Me too, 200 Euro!
Ciao
Walter
A handy guide to financial support for open source.
"I do open source work, how do I find funding?"
https://github.com/nayafia/lemonade-stand
Ciao
Walter
According to the latest Mobian update https://blog.mobian.org/posts/2024/01/08...s-of-2023/ it seems that they intend to do work related to Wireplumber/Pipewire and call audio this year. It is unclear exactly what this means, but maybe it will help in getting this bluetooth hfp problem fixed.
I would hope that those who can will add any amount they think appropriate, and that those who can't contribute would at least register their interest.
If someone knowledgeable about such things were to set up some more formal way to do this I would be glad to see it. Either way, I will stand by my offer.
Thanks to the large pledges of 33YN2 and walter1950, the bounty is now around (depending on exchange rates) $467 or 430 Euro.
03-17-2024, 04:19 PM
(This post was last modified: 03-18-2024, 04:17 PM by JohnA.)
I have managed to get some degree of functionality with this on my pinephone pro. Not with a new pipewire profile, but rather with some amixer changes to the sound card to provide "dangling software wires" for the inputs and outputs to the phone modem, and then a perl script to monitor every second for a voice call state, and then use the pulseaudio / pipewire module-loopback to connect all the available ports together, and reset the state when the call is ended. I should acknowledge that I've used some of megi's insights into the device to get where I am now.
This does not implement the ability to type in a number using the car interface ( rather more advanced than I can get my head around), but it does work quite well, with decent audio quality and without doing any fiddles the system ( at least in my car ) does not feedback between the two audio channels and maybe cuts between them well ( but I'm not sure exactly what it does, only that it works). But you can type in a number into the pinephone, and after a few seconds it will notice the voice call state and hook up the bluetooth interface to the bluetooth effective mic and speaker. You can also answer a call too, but it can get confused if you are playing audio on the car system. Also, in can get confused about the voice call state, but I may have fixed this problem, I've not had it for a while now. I personally find this "hack" satisfying and worth using, gives me a good use of the pinephone pro while driving around.
I'm happy to put the effort into making it available for the said bounty - equally, I know that in the fine tradition of you get an answer to a question on the internet by asking the question and then posting your own wrong answer, similarly the real experts only get involved when they know someone is making a half-arsed attempt because they don't want to get shown up. Further, I'll donate 10% of the bounty to megi if he wants it and this actually happens and I get my paws on it.
Well, if I prompt people to actually write the necessary pulseaudio/pipewire profile, I don't mind missing out on the bounty as long as I get a better solution for my own pinephone pro. I wrote it because I couldn't find anything better out there.
But ... there's the bounty ... and here's a nibble. Is a perl script hack what people are willing to pay for, or does it need to be the "profile" mentioned? Clearly I need to identify myself better than just being some random voice on the internet, but one thing at a time.
(03-17-2024, 04:19 PM)JohnA Wrote: I have managed to get some degree of functionality with this on my pinephone pro. ...
I hadn't checked on this for a few weeks. Thanks for taking the time to make a thoughtful response. As for being a random voice on the internet, as far as I'm concerned I don't see any need for more than that until it comes time to collect.
I can only speak for myself, especially since the amount I've promised toward the bounty is now a relatively small part. I'd be interested in the opinion of those who made larger pledges. So with that caveat, in my view:
The bounty is for a solution which enables users to make and receive calls using hands-free bluetooth devices compatible with hfp 1.5 and later over a bluetooth connection with a pinephone original.
I have assumed that the simplest and cleanest way was to set up the correct pipewire/wireplumber configuration, and that since it looks like that is the direction Debian, Mobian, and others are going, that that would be preferable in the long run. But, if there were a solution using some other approach, that was compatible with the original pinephone, is functionally equivalent from a user perspective, and which could be used by the typical pinephone user, in my view that would satisfy the conditions I stated for the bounty.
As things stand now, it is possible to dial out on a bluetooth device and have the call be properly placed, for an incoming call to cause the bluetooth device to ring, and to use it to "pickup". The bluetooth device can also hangup. The only missing part is that the audio isn't being routed from the phone to the bluetooth device or from the bluetooth device to the phone.
It sounds like you've come up with a solution to the audio routing piece, at least for the pro, but it doesn't include the rest of the call process. One concern I'd have about using a script to monitor for a call is whether it would significantly affect battery life or increase the temperature since both are already a problem with the phone, but I could easily be wrong in that.
It also sounds like you've made a lot more progress on this than any of the "real experts", many of whom (Megi for example being a clear exception) are good at playing around with it as a toy while it is easy, but don't have what it takes to stick with it to do the serious work of actually fixing things needed to make the phone useful for ... phone calls. I don't think what you have satisfies the conditions of the bounty, but it is a step in that direction and I am grateful for your taking the time to describe what you've done.
OK, conifera ...
I can get a bluetooth headset button pause and restart an audio track playing to the headset, but are you saying you can type in the number to call from an external bluetooth device? Which app is doing this? Are there details of the installation anywhere? And what version os are you running? If that's the case, I could incorporate it into my existing system, with my script providing the audio connection and whatever app running to do the external bluetooth dialing input.
As for the load, the phone will still hibernate. But it may be possible to alter the script to trigger off dbus with a select statement (?) with a very reduced load ( or maybe some other approach ). I could also get the daemon running via systemctl. For the present, though, I just wanted something that worked, and it is good to watch it in operation for debugging purposes, and enhancements could follow if I had the time and interest.
Anyway, curious to understand your setup better.
JohnA, I'm sorry I didn't answer sooner, I'm pretty swamped.
Quote:but are you saying you can type in the number to call from an external bluetooth device?
Yes, exactly. I've got a bluetooth device paired with the pinephone. You dial the number on the device, it signals the pinephone, the pinephone makes the call as if you had dialed the number on it, but you don't have to touch the pinephone at all.
Assuming someone answers at the called number, you should be able to talk through the device. Instead the audio never gets routed over bluetooth so you have to pickup the pinephone to carry on the conversation (which mostly defeats the purpose). Then you can hangup via the device and the pinephone ends the call.
From the other direction, someone can call, the pinephone signals the bluetooth device which rings. You pickup using the bluetooth device, but again the audio doesn't get routed so you have to pick up the pinephone to carry on the conversation, (again defeating the purpose).
This all works perfectly on android. All you have to do is pair the phone with the device and the rest is automatic.
It's been quite a while since I've messed with this but as I remember, all of the signaling between the phone and the bluetooth device are supposed to be handled by AT signals (See https://dylanvanassche.be/blog/2022/blue...ux-mobile/ reference in this thread https://forum.pine64.org/showthread.php?...etooth+hfp) and I think all of that is probably working. Just the audio rerouting over bluetooth isn't working.
It was all supposedly in pulse audio, but my understanding of the audio systems is very minimal and I could never get it to work. It is also supposedly in pipewire/wireplumber, which I got to work only as far as I describe above. I'm convinced it would be trivial to fix for someone familiar with either of those systems, but they would have to work out the specific configuration for the pinephone or pro. As far as I understand it, the configuration details will be different between the two.
Quote:Which app is doing this? Are there details of the installation anywhere?
No special package. Everything is handled by the bluetooth system and the audio system. But it is so abstracted and so poorly documented I gave up trying to figure it out. I'm running a pretty old version of Mobian. It's stable for what I need so I've not wanted (or had time) to mess with it until I see that there is a solution to this in some newer version or other OS.
It sounds like you could easily minimize whatever load your approach has if needed. I can certainly understand the advantages for debugging and generally leaving it as is unless you had time or a good reason to change it.
Confera,
OK, so I've hit a few roadblocks, not so simple.
My phone runs pipewire, and this interfaces to alsa and also sets up the bluetooth device so I can connect to it. Bluetooth comms are done via the bluez library, but pipewire provides an "audio device".
Your suggested AT bluetooth interface runs within pulseaudio, and it is a fiddly version which barfs when it connects to devices, it could be the alsa interface which was previously provided by pipewire. But I can get another "simpler" version of pulseaudio to run on my phone. But it is hard to get pulseaudio, rather than pipewire, running on my phone. And pipewire does not have that AT bluetooth interface.
Still, I think ofono is *supposed* to run this interface, but I've never had it spring to life. Maybe with this additional knowledge I'll be able to make it do so.
So, maybe I'll get something going, but it seems different someone incompatible versions of the various programs do different things. Maybe I'll be able graft something important from something else to something that actually starts properly, but we'll see.
|
