Calls Application and Microphone Permissions

There is already a thread about the microphone not working during calls. However, that thread dealt with issues such as the hardware switch being turned off, or the use of an unstable alpha version of Gnome Calls. I have a similar problem, but I believe it relates to permissions for apps to access hardware, rather than to the issues in the existing thread.

[EDIT 4 March 2023: Hardware permissions are not the cause. Various other suggested causes are disproved in this thread (including theories about network configuration). So far there is no further suggestion beyond those that have been disproved. One fact that has been established is that audio can be sent from the Calls app to the SIP server in the form of DTMF tones before a call is connected (thus enabling calls to be dialled), while neither microphone audio nor DTMF tones go from the Calls app to the server once the call has been connected. One user does report two-way audio on a VoIP call from Calls on his L5; so far only the one user has reported this success, while several others report one-way audio only.]

Possibly this merits an entry in OS-issues. Advice from more experienced users would be welcomed.

With settings for my VoIP provider in the Calls app, the app works beautifully, except that there is no outgoing sound. (No problem with ringing whether for incoming or outgoing call; the ringing stops as it should when the call is picked up. Incoming audio is high quality and smooth.)

(I have not tried Calls on a cellular network and do not intend to use the Librem-5 for cellular calling in the country where I live.)

The hardware switch for microphone and camera is turned on.

In Settings>Sound>Input>[Handset Microphone - Built-in Audio]
the indicator line of dashes responds strongly to sounds, showing that the microphone can communicate with the OS.

Downgrading to 43-beta version made no difference. I have reverted to the latest 44-alpha.

The contents of Settings>Privacy>Microphone suggest the possibility of a Permissions problem. The following two paragraphs appear there:

“Use of the microphone allows applications to record and listen to audio. Disabling the microphone may cause some applications to not function properly.”

“Allow the applications below to use your microphone.”

Below those paragraphs there is a box with the further message:
“No Applications Have Asked for Microphone Access”

It appears that there should be a drop-down menu of apps, or some facility for writing the name of an app (specifically Calls in this case) in the box, to allow the app to use the microphone. However, those things do not exist on the page, or anywhere else that I can find in the GUI. I am not keen to delve into udev rules to fix this problem.

I have a vague memory that, during the initial setup 7 weeks ago, there was a question about app permissions for mic and camera. I may have opted not to allow access, assuming that this could be easily reversed. That does not seem to be the case.

1 Like

I believe this is only populated if the app is running.

1 Like

Thank you for the suggestion. However, at the moment the app is running and the VoIP connection is active (confirmed by registration on the VoIP provider’s website). The Privacy page has not changed.Did you mean that there has to be an actual call in progress before the change can be made?

Update: I have just made an “Echo Test” call to my provider’s server. I spoke at length into the microphone during this call. The Privacy page did not change at any time during the call. There was still no facility for allowing the app to access the microphone.

Not near a machine I can test on, but try in terminal

gsettings set org.gnome.desktop.privacy disable-microphone false

Suggested by web search.

Edited. Damned autocorrect.

1 Like

Thank you very much again for taking the time to search. However, there is no difference after entering the command, or after entering it again during a call.
I am going to try again, replacing “desktop” with “librem-5”. Do you know where this setting is held in the file system - somewhere in /etc perhaps?

Update: I tried replacing “desktop” with “librem-5” and then with “librem5”. Both attempts returned “No such schema”.

I don’t, but it’s starting to sound like the issue is with calls and not the OS. There’s an audio recorder app, isn’t there? Have you tried with that?

1 Like

There’s an audio recorder app, isn’t there?

I haven’t installed that yet, but I’ll do so now and see what happens. Thank you again.

In the middle of installation, I notice that the sound recorder comes from flathub. I understand that there’s an app from flathub specifically for checking and changing hardware permissions for their apps (though not for github apps).

UPDATE: Recording worked fine. The Privacy page still says that no application has asked to be allowed to use the mic. It says this even when the sound recording is in progress, when that app is obviously accessing the mic. It looks as though the Privacy page does not in fact serve any function.

So, as you say, it looks as though the problem lies with the Calls app.

2 Likes

I sometimes experience this problem. I can hear the far end, but they can not hear me. Sometimes it helps to enter the following commands:
pkill gnome-calls
pkill pulseaudio
Before restarting gnome-calls and calling back. Sometimes I have to do a reboot of the phone. One time I saw that mic input was set to 0 under sound settings, and turning this back up solved the problem.

2 Likes

Thank you for the suggestion. I am waiting for the phone to charge and will then try again. I note however:
(1) This is not a “sometimes” situation. It is every time.
(2) Many times I have tried Calls directly after booting up. I think that that more or less replicates the reboot or the pkill-restart that you suggest.
(3) On first trying Calls, and noting the lack of outgoing sound, I set the mic volume to a high level. It has not moved from that level. I have also tried with the built-in stereo mic instead of “Handset Microphone - Built-in Audio”; it made no difference.

Not necessarily. If there are timing or dependency problems in the boot procedure, restarting after the boot might just workaround something.

You should be able to use arecord for a low tech recording, in order to verify a sound source. There are two microphones that could be a sound source (as well as the modem but that might be difficult to test).

1 Like

Thank you for this explanation. I have done the pkill commands and tried again. There is still no sound going out to the server. The Echo-Test instructions from the server come through perfectly, as before.

Yes, I have tried with both the mono and the stereo mics. The modem is switched off, because I want to make a VoIP call, not a cellular one. If I turn the modem on, how can I ensure that I am not making a cellular call? Actually, even with the modem switched on, the corresponding dashed line in Settings>Sound>Input makes no response to noises near the mic.

Well, I have just done it with the modem turned on. Luckily the VoIP provider’s Echo Test number means nothing to the cellular provider. Call went through to the server as usual: server’s message perfectly clear; nothing communicated from my end.

Thank you very much for pointing me to gsettings, from which I was able to find that the primary codec used by the Librem-5 is G.722. That is a Beta option with my VoIP provider. I have now activated it, and it might perhaps be useful some time in the future. For the present case it makes no difference, probably because the other Librem-5 codecs were already active in my VoIP account.

CORRECTION 8 Mar 2023: Codec PCMA is not available with my VoIP provider, and G.729a is not available for Calls app in L5. These turn out to be the crucial facts.

1 Like

Thank you for this, but I am a bit puzzled whether arecord would make a better test than the Sound Recorder from the PureOS Store (which I installed at Gavaudan’s suggestion, finding that the mic communicates with it faultlessly). Does the low-tech aspect mean that its handling of audio more closely resembles that of Calls (as opposed to the high-quality .flac recording of the Sound Recorder)?

The next thing I am going to try is to use a different wifi access point. The Librem-5 and my GL-AR750S don’t always get along with each other, and I have to boot up another device to make the GL pay attention. It would still be a bit odd for the Calls failure to be a wifi problem, in that the audio is absolutely dependable in one direction but absolutely absent in the other.

It might take me some time to set this up. I have to fetch the other AP/router from a storage unit elsewhere.

GOOD NEWS: Cellular calling works fine. I will see whether the VoIP problem is related to the languid browsing on Librem-5. More detail in the next post.

Very many thanks to Gavaudan, krimskrams and irvinewade. I have learned quite a lot from you.

VoIP calling still has the stated problem, which I suspect might be related to dns.
[Correction: See update below. It is not a DNS problem.]

However,
I borrowed a SIM and turned on the modem. Cellular calls were made successfully to and from the Librem-5. So the mic is speaking to the Calls app and the Calls app is making and receiving calls.

It looks as though the VoIP call problem might be part of the disagreement between the phone and the AP. The Librem-5 can be browsing OK and then suddenly gets stuck. Any notification that appears is something on the lines of “Unable to find that domain.” As mentioned to irvinewade, I can usually get round that by booting up another device: once the other device connects with a website, the Librem-5 also starts connecting to whatever I wanted it to, as close to immediately as I can tell.

I will try with another AP, but I have to say that it seems like an error for the Librem-5 to need an assist from another device before it will do its job.

UPDATE: It is not a DNS problem. I reconfigured the VoIP settings with the server’s numeric address. There was still no outgoing audio.

For what it’s worth I’ve had the same experience with sip calls using gnome calls. I think something is broken in the audio chain in the app or something.

1 Like

Not really. It wasn’t my intention to imply that. However arecord might be there out-of-the-box (is it?) and it is a simple sanity check.

The intention was just to do anything that will demonstrate that the mic is working as it should, hence pointing the finger at the Calls application or something else.

Sound quality could make a difference - because the sound quality that an application requests could determine the set of audio sources that it can use.

Seems doubtful, as you say. However you might also have a (different, unrelated) WiFi problem.

I’m not familiar with this device but what technology is on the WAN side of this (in your specific case)?

Regardless, if it’s routing from WAN to LAN then it could easily break VoIP (and the WAN side itself could easily break VoIP). Does any device that is connected to this router on the LAN side successfully use VoIP? In other words, have you ever used VoIP successfully with this network setup (long before the Librem 5)?

What do you mean by “cellular calling”? Do you mean a completely conventional cellular phone call? Or do you mean VoIP over a data connection established via the cellular network?

My guess is that it “suddenly gets stuck” (communication with the network ceases to work, temporarily or permanently) and hence that failure to resolve host names is a symptom of that. So, not a DNS problem, but a generic network problem.

PS Are you trying to use this with a VPN or not yet attempting to do so?

Very many thanks for all this attention. I’ll answer more completely tomorrow. Sorry to be busy this evening.

Do you mean a completely conventional cellular phone call?
Answer: Yes, and it worked fine. No wifi, no VoIP involved.

not a DNS problem, but a generic network problem.
Answer: On the same network, this problem does not happen with my 7-yr-old LG25 phone on FirefoxOS, nor on my Chromebook running Linux Mint.

Are you trying to use this with a VPN or not yet attempting to do so?
Answer: Not yet. Should a VPN make it better or worse?

Not sure that you have seen my latest post or the later post from raenrfm.

Many thanks again for all your help.

OK, that’s good fault isolation that both of those can make VoIP calls in this setup.

Probably worse, certainly more complex and more points of failure. However it could also paper over some other problems so it would be good to try both with and without.

So quoting my own comment …

that would completely bypass WiFi and the router and hence start to fault isolate.

No, I meant that they don’t have the problem of just stopping browsing until another device comes along to wake up the network. It might be something to do with the sleep-mode of the AP and a possible inability of the Librem-5 to get it going again. Neither of the said devices has a VoIP client, the LG25 because Firefox abandoned its OS for small devices shortly after I bought the phone, and the Chromebook because it’s not something I would want to use for phone calls.

I do have a device that makes VoIP calls very well on the network in question, or at least on the 2.4 GHz branch of it. It is a Nokia N800 Internet Tablet, one of the Maemo devices from 15 years ago. Interestingly, its SIP client is an ancestor of the Sofia client incorporated into gnome-calls.

I could activate the AP’s 2.4 GHz radio and try the Librem-5 through that, if you think doing so would yield useful information. That will have to wait at least until tomorrow.

This connection is not as straightforward as you might be thinking (and in fact it didn’t work at all). There are several factors involved:
(1) I am currently located in Toronto, Canada;
(2) My VoIP account is configured to a server also in Toronto, Canada;
(3) I opted for a European modem in the Librem-5, because I have no reason to use cellular mobile internet except when I am in Europe (or perhaps when a well-meaning person tells me I should use it for a particular purpose);
(4) The only data-enabled nano SIM that I have available is for a prepaid account with a provider in the UK;
(5) The Calls application does not ask whether a particular call should be VoIP over cellular or a completely conventional cellular phone call, and it is therefore understandable if the roaming cellular network is unable to place the call either way. (Further, it is quite possible that Bell Canada blocks VoIP packages for prepaid roaming non-customers.)

It is incidentally important to me to retain the prepaid balance on the UK account, because I seldom visit UK (the only place where I can top it up) and because I can use it very economically throughout the EU and the USA, though not in Canada. In the attempts this morning, I have depleted the precious balance by approximately ÂŁ2.