Make & receive call from PC

[tvld]

With a VPN, we should be able to connect to a phone I leave at home.

If I could make calls on that phone from my PC, it would be really useful when traveling or working remotely...

[andyholmes]

Unfortunately neither the Android app or protocol has support for audio streaming or making phone calls.

You can open a new issue for the Android app on the KDE Connect bug tracker: https://bugs.kde.org/buglist.cgi?component=android-application&list_id=1646262&product=kdeconnect

[tvld]

https://bugs.kde.org/show_bug.cgi?id=410149

[andyholmes]

Thanks for filing upstream. I'm actually going to re-open this since it has a linked report, although I think it might be awhile for this feature :)

[pvagner]

This is very unlikelly to be doable on android because android vendors and Google don't allow streaming call audio to 3rd party apps.

[ferdnyc]

Best we might be able to do is act as some sort of "helper", to facilitate pairing the PC's audio devices to the phone over Bluetooth... but I suspect we wouldn't even be able to make that process appreciably easier, really.

[tvld]

@ferdnyc creative idea ! If the phone thinks it is just using a " headset", it will happily accept calls it seems. But can that be done over OTG USB connection as well? Then we can just plug in the phone into an USB port? After all, using OTG we can use USB headset on Android as well...

[ferdnyc]

@tvld Honestly, I have no idea if that would be possible. But if it is, it would probably require some sort of driver (or at least udev) support on the Linux side. Something would need to "proxy" the system audio devices as (fake) USB audio hardware, the same way BlueZ proxies them as Bluetooth audio endpoints. Which takes it completely outside the realm of GSConnect's featureset.

[koter84]

i have a fedora tablet (surface) which i use for teams and spotify, with my bluetooth headphone connected. so i wanted to pair my phone to the tablet, where the tablet would act like a headset, and loopback the call-audio to/from my tablet mic/headphone. it seemed quite easy since fedora says it can act as a headset, but i only got it to work for media-audio from my phone, as soon as a call comes in the audio streaming isn't working anymore. so i got a wired headset and plugged that into the tablet to test if it would work wired, turns out that works flawlessly. i ordered a 4-pin 3.5mm audio jack male-male cable, and now that connects the call-audio to my tablet :smile: if you setup pulseaudio over vpn you should be able to stream your call-audio to wherever you are. i also hacked around in gsconnect to trigger a bash script for setting-up the loopbacks and removing them after the call.

[tvld]

@koter84 Well... actually... I think you might be really on to something ! Can you elaborate a bit more? As I dont understand how the end-setup is fully working? Maybe a sketch ?

[koter84]

hahaha...

so in short... i use a 4-pin audio cable since that has GND+L+R+MIC, this connects the headphone jack from my phone to my tablet

i have my bluetooth headphone connected to my tablet over A2DP for high quality stereo audio and a Playstation Eye Camera connected over USB (this is what i had lying around because of a diy-alexa project some time ago)

with everything connected i call a script when a call comes in:

jack_mic_name="alsa_input.pci-0000_00_1b.0.analog-stereo"
jack_spkr_name="alsa_output.pci-0000_00_1b.0.analog-stereo"
wh1000xm3_name="bluez_sink.38_18_4C_95_84_B1.a2dp_sink"
pseye_name="alsa_input.usb-1415_USB_Camera-B4.04.27.1-01.multichannel-input"

pacmd load-module module-loopback source=${jack_mic_name} sink=${wh1000xm3_name}
pacmd load-module module-loopback source=${pseye_name} sink=${jack_spkr_name}

and when the call is done i unload the pulseaudio loopback module with:

pacmd unload-module module-loopback

you can find out the source and sink names you need with:

pacmd list-sources
pacmd list-sinks

[koter84]

pulseaudio over network is quite easy to setup, install/open paprefs and enable sharing of audio ports on the machine with the phone connected (tablet in my case), and enable using of discovered audio-ports on the "remote" machine, i'd suggest to try this in a local network since then you have autodiscovery etc. you should then easily be able to select the audio-input and audio-output from the "tablet" and use those for the loopback-module

[koter84]

only thing i want to implement is running the script from within gsconnect in a non-hacky way.

i have a working proof-of-concept in my own repo: https://github.com/koter84/gnome-shell-extension-gsconnect/commit/f1ec522a33f642bf999132d08d55619f0f25ab4e

but i would like to run a command from the commands-list and be able to select that from the telephony settings page. i'm not very familiar with gjs, so at the moment i do not have a clue how i would call the command through the runcommand-plugin... any pointers on that?

[ferdnyc]

pulseaudio over network is quite easy to setup, install/open paprefs and enable sharing of audio ports on the machine with the phone connected (tablet in my case), and enable using of discovered audio-ports on the "remote" machine, i'd suggest to try this in a local network since then you have autodiscovery etc.

For all the hate PulseAudio gets, it is the bee's knees for that kind of stuff.

I run an MPD daemon on my headless fileserver, to serve as a jukebox for my music collection. Normally, it outputs to the Logitech surround system hanging off my desktop computer's USB audio interface (accessible over the network, as you outlined).

Every time I plug my laptop into the stereo in the next room, and redirect the music to it in a couple of mouse clicks (and without even pausing the song) — it feels like I'm living in the frickin' future, man.

[ferdnyc]

i'm not very familiar with gjs, so at the moment i do not have a clue how i would call the command through the runcommand-plugin... any pointers on that?

I wouldn't use the RunCommand plugin for that, personally. Just because, then you have to have RunCommand enabled in order to have the command executed by Telephony, and you might not want that. Executing commands on request from a paired device vs. automatically based on local events are pretty unrelated features, really.

Easier to just add a "Run this script/command when a call comes in" field in the Telephony configs, IMHO.

(Sure, maybe RunCommand's internal launcher can be leveraged for its process-spawning code, or that can be abstracted out in a way that's available to all of the plugins that can make use of it.)

[ferdnyc]

(The idea of having a custom script executed in response to an incoming call, that part I think is awesome!)

I'm even tempted to suggest that info like caller identification could be exported to the script environment, so it could potentially be able to make informed decisions about what actions to take in response. But that opens up a can of privacy worms, even if it is only on the local system. Unix process environments are hardly a secure playground for personally-identifiable data.

[andyholmes]

I have some free time tomorrow, so I'll look into abstracting the launcher from runcommand.js so it can be re-used. It might even be best to bump it up to device.js anyways so commands can be tracked killed if a device becomes unpaired.

After that it's just a matter of adding some rows to the telephony preferences to select a command. I think one script for each of Incoming & In Progress is fine, since those scripts can fork if they need to.

[koter84]

i'll wait for your commit with the abstraction of the run part, and then give it a go to make some extra fields in the ui for inputting a command. should be doable in the next couple of days

[andyholmes]

@koter84 see #809 and let me know if that suits your purposes.

[koter84]

@andyholmes that looks like it would definitely do the trick :-D i think i'm on the right way with the glade-ui but i'll do some more tests with that tomorrow

[andyholmes]

Sounds good. For what it's worth, I usually find just editing the XML directly easier. My experience with RAD tools is toolkits are often just to complex for an editor to really be intuitive.

[minat0namikaze]

Its already being done on windows right? https://www.cnet.com/how-to/you-can-now-place-and-receive-android-phone-calls-on-your-windows-pc/

[tvld]

@minat0namikaze that seems to work over a Bluetooth connection, where the PC functions as a headset. That has been possible before )

[ferdnyc]

@tvld @minat0namikaze I think there may be slightly more to it than that, just because their desktop app does get caller ID (like I outlined in https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/575#issuecomment-606944875 and then immediately walked back), plus it can dial the phone to make calls. Those aren't functions that would typically be performed by a Bluetooth headset, at least not in the typical media-control-with-bidirectional-audio configuration, and they're a bit above-and-beyond the current Telephony support available to GSConnect via KDE Connect.

But the fact that Microsoft can apparently provide all of those features in a third-party, app-store-downloaded, non-privileged app, on the Android side, is pretty encouraging. There's no obvious reason why KDE Connect couldn't request all of the same permissions, and have access to all of the same APIs.

Nevertheless, it remains a ball that would have to be gotten rolling on the Android app end of things first. I'm pretty sure KDE Connect is lacking support for several of the APIs required to make all that work.

(Edit: The fact that it only requires Android 7 or higher is also surprising, in a good way.)

[minat0namikaze]

Yeah it would be good if that was possible using gsconnect similar to what microsoft did :)

[ferdnyc]

Well, again, nothing is possible with GSConnect except what KDE Connect supports on the device end. Anyone who wants these features needs to make their case to the Android app developers.

[rahra]

@koter84

so in short... i use a 4-pin audio cable since that has GND+L+R+MIC, this connects the headphone jack from my phone to my tablet

I wonder how the cable is wired. Because if it is just straight connected from the left to the right it would connect the mic input from the phone to the mic input from the tablet and the outputs together which IMO cannot work.

Is the cable internally a cross-over cable? So from mic to speakers and vice versa?

[drishtantr1508]

This is very unlikelly to be doable on android because android vendors and Google don't allow streaming call audio to 3rd party apps.

This is Very possible on android. Microsoft's your phone app uses similar technology to transfer calls on pc from Android then why not KDE connect.

[koter84]

@rahra

I wonder how the cable is wired. Because if it is just straight connected from the left to the right it would connect the mic input from the phone to the mic input from the tablet and the outputs together which IMO cannot work.

Is the cable internally a cross-over cable? So from mic to speakers and vice versa?

i created the cable myself, and connected L+R -> MIC and MIC -> L+R

but i never really got it working properly

[rahra]

@rahra

I wonder how the cable is wired. Because if it is just straight connected from the left to the right it would connect the mic input from the phone to the mic input from the tablet and the outputs together which IMO cannot work. Is the cable internally a cross-over cable? So from mic to speakers and vice versa?

i created the cable myself, and connected L+R -> MIC and MIC -> L+R

but i never really got it working properly

Ok, thanks, that explains a lot. It does not work properly because of the different voltage levels and impedance. You would have to match it with a small electrical circuit or I think it should work by using a DI box: https://www.thomann.de/gb/di_boxes.html?ref=intl

[ky56]

I understand that this won't work on android but what about support for the Pinephone? Surely it would have the API's to do this?

[andyholmes]

You can stream audio, video, games or anything else to/from a KDE Connect device.

It just won't do anything because the KDE Connect protocol has no way to describe what to do with this data. Protocol changes must happen upstream in the KDE Connect project before they can be implemented in GSConnect.

[ferdnyc]

@andyholmes That statement is turning into our version of, "Have you tried turning it off and on again?", isn't it? 😆