in-call muting of the microphone does not work

when phoning with someone, pressing "mute" will not mute the microphone

Confirmed, the button will show up highlighted when pressed, but is nonfunctional otherwise. Which can easily lead to embarassing situations :-).

Yes, you can thank pulseaudio for not implementing proper HW mute support: same as with echo cancellation, as the stream is purely hardware, we need to act on the HW mute switch instead of trying to do things in software, as pulseaudio does.

I should check how latest pipewire behaves in this regard, this could be a good reason to switch if it works...

Also tested and just want to confirm. Finally popped in the SIM and everything else is working w/ calling.

Since this will not work for the foreseeable future, it would probably be best if we patched the UI to make the mute button insensitive

Worked around with https://gitlab.com/mobian1/packages/gnome-calls/-/commit/cedded1a830c340176a94138faaa644785c326f1 by disabling the button

closed

Technically this still issue is still relevant. In-call muting doesn't work.

Technically you are correct, which is the best kind of correct.

Reopening, but labeling the issue with "workaround"

reopened

added workaround-available label

So does the "pinephone cannot fly" issue :-). The lack of muting is a hardware-determined issue and while we all want it to work, this will not be easy to achieve or work in the same way as it works on purism's librem.

Would the Purism guys then even be interested in merging a hypothetical fix for the PP if it Works On Their Device™? If not, would that mean that a) there would need to be a PP-specific fork of Phosh, or b) all the distros supporting the PP would need to roll with downstream patches for it?

Of course, they have plenty of patches that are specific to other devices, or distros (e.g. a pinephone-specific feedbackd profile, or patches to support the ofono backend instead of modem manager). However, this is nothing phosh-specific, so phosh is not involved here at all.

First one would need to find a way to mute the microphone before one can even thing about how to offer a patch to gnome-calls... As commented above, this is not trivial.

Maybe I'm off-base, but why do we have to do things identically to Purism? We are already communicating w/ the modem and it has its own AT+CMUT control.

When I get some time I'm going to dig into it a bit. I don't have a SIM installed at the moment so can't test calls:

Someone else might want to try:

mobian@mobian:~$ mmcli -m 0 --command=AT+CMUT?
response: '+CMUT: 0'

and

mobian@mobian:~$ mmcli -m 0 --command=AT+CMUT=?
response: '+CMUT: (0,1)'

Can't set it unless a call is active, as the parameter is not retained and thus all new calls would be live. I get that people want to toggle mute on the mic, but since Gnome-Calls has one purpose, and that's to make voice calls (via MM), it should be sensible enough to have the modem do it as well.

Most likely not the best patch, but make it work to be able to mute the MIC on a pinephone. ATINOUT would need root access ...

Some talk snippets from the Pine64 Developer Channel:

smaeul: assuming CaptureMixerElem means "the kcontrol for the input to the mixer widget", it could be any of "Mic2 Capture Switch" (Mic2 input to ADC mixer), "AIF1 Data Digital ADC Capture Switch" (ADC input to CPU capture mixer), or "AIF2 ADC Mixer ADC Capture Switch" (ADC input to modem capture mixer) or it could mean something else entirely. all use-case.h says is "mixer element capture identifier"

Bhushan Shah: I am not toggling it with UCM, I am just specifying "Mic1/2 Capture Switch" as CaptureSwitch, so maybe pulseaudio/pipewire is not using it properly?

smaeul: well there's always the option of shelling out to amixer (which would still be an improvement over AT commands)

Bhushan Shah: [I][000000240.387904][acp.c:1853 acp_device_set_mute()] Set software mute: 1

smaeul: clearly software mute isn't going to work...

Bhushan Shah: adding CaptureVolume "ADC Capture Volume" made it set to mute when I sent sound to 0. I guess I can adapt plasma-dialer to set capture volume to 0 in addition to hardware mute

Thanks for posting this!

I've been talking with @a-wai a bit and maybe we will have something working with pipewire without needing any hacks ;)

At least in Mobian we're not going to apply the patch as it is (but thanks anyway for bringing it to our attention!), because we need to take other supported devices into account.

Actually I've been thinking that some part of the stack (maybe callaudiod - maybe not?) should maybe have some device configs/profiles (describing available peripherals and/or device quirks?). This will definitely require some more thought.

Fix is rather easy, 2-3 lines of code pa_context_set_source_volume_by_index at https://gitlab.com/mobian1/callaudiod/-/blob/master/src/cad-pulse.c#L753 I think. Besides that function, you need to save the volume before muting in a variable and set it back when umuting. UCM is already prepared and Plasma-Mobile went for it already.

FYI: Callaudiod is handling mute button, loud speaker and audio profile switching. Also there is SIP and ofono, so you definitely don't want to do run mmcli unconditionally (or the same programmatically).

If you come up with a patch (either for Mobian or something that is acceptable upstream) feel free to prepare a MR.

Thanks. I'm only running mmcli as a test and understand the point.

For what it's worth, I think that people would rather have a phone that works correctly as a phone than have a calling application that can do a lot of things but can't mute regular phone calls correctly. It's a critical component of a phone.

In any case, I'm not even aware if SIP et al. is receiving the audio in the same way as the modem. I've not even investigated it. I've not even tried SIP calling so far. These are just some ideas to get people to think outside the box rather than limiting our options to relying on pulseaudio and the hardware mic mute situation.

Regarding a patch, I wouldn't want to waste my time if you think it's not going to be a proper solution. You know more about this than I do.

If that works it would be nice to make a two-button GUI with yad for mute and unmute and have it documented as workaround in the Wiki.

That having said, using the AT CMUT command whenever appropriate sounds like a good idea. As @devrtz pojnts out though, that is not so easy due to the different backends for valls and the various possible audio routings.

If all that needs to be done is send an AT command to the modem, can't atinout be leveraged? AFAIK it's independent of MM and ofono, all it needs is the AT command and the modem's ttyUSB interface that can interpret it.

That should work but is pretty hacky imho.

Seems AT CMUT only works in 001.01.001.01 and 001.02.001.02 firmware for the eg25 modem. In the newer 001.03.001.03 it creates an error. See also here.

Just for the records, while quectel seems to have silently removed the AT CMUT command in the 003 firmware, the latest releases of biktorgj's nearly-FOSS firmware have reinstated the feature.

On a related note, the modem also has built-in echo cancellation w/ AT+QEEC but the 50 parameters appear to require a special document that needs to be obtained from Quectel.

If "Mic1 Boost Volume" and "Mic2 Boost Volume" kcontrols are renamed to "Mic1 Capture Volume" and "Mic2 Capture Volume" and mute button during a call started to work. pulseaudio in this case starts to reuse HW mute and volume controls.

I'm not a fan of this approach, as the kcontrols names should reflect the reality. In this case, MicX Boost Volume is an appropriate name as it effectively acts on a preamplifier (== booster), and at its lowest value it doesn't cut the signal, but rather leaves it untouched (0dB gain).

However, this shows PulseAudio only picks up HW controls if they contain a volume control. Fixing PA so it can handle cases where only a mute HW control is present would be the way to go IMHO.

That's a good finding anyway, thanks for sharing!

It uses HW mute and actually cut the signal, but apparently HW mute picked up only if there is actual hw volume capture control. Agree, that fixing PA would be more correct solution. I've not looked into details of PA implementation yet.

Hello,

Mobian issues are now tracked per-project/package in the corresponding Salsa group.

As a consequence, this repository will be archived in a few weeks. If your issue is still valid, please re-create it in Salsa, possibly summing up the discussions here if you feel those can be helpful.

Thank you for your contribution(s)