Hardware switch for mic is not working properly

[submariner]

I'm just at the beginning of my testings. But I can confirm that it is possible to hear at least the OS itself sounds from pinephone, when I'm using mumble and doing volume up volume down one a pinephone it is possible to hear those volume adjustment beeps on the other end while mic is supposedly switched off by hardware switch.

KDE Manjaro CE

[bcnaz]

Could that be classified as "System Sounds" rather than microphone sounds ?

[cndg]

How are the DIP switches physically wired?  Is there a PCB diagram to prove that they're not just a software trick?

The reason I ask, is that other smartphone vendors have made "hardware privacy claims" that have, many times, proven to be lies... such as cameras with LEDs (except the camera can still be enabled without the LED illuminating) and "sub-dermal blah blah" about fingerprint sensors (which were still bypassed with a gummy bear), and those are just the tip of the iceberg, because about 99% of all "security" claims are never actually verified.  Stick a "printf()" inside the gnupg/openssl/etc prng "seed" function (the code that bypasses system entropy) to see what I mean...

[beta-user]

I'm just at the beginning of my testings. But I can confirm that it is possible to hear at least the OS itself sounds from pinephone, when I'm using mumble and doing volume up volume down one a pinephone it is possible to hear those volume adjustment beeps on the other end while mic is supposedly switched off by hardware switch.

KDE Manjaro CE

I think that makes sense. With your microphone turned off Mumble probably just switches to the only other input source available which is the system. Install and run pavucontrol, then go to the recording tab to confirm which audio source Mumble is using.

Stick a "printf()" inside the gnupg/openssl/etc prng "seed" function (the code that bypasses system entropy) to see what I mean...

Just out of curiosity what happened when you did that and what did it prove?

[bcnaz]

That is a known "BUG"  I have seen posted for some time  at the Mobian blog site.  It is probably on other operating systems websites as well.
though I did not delve into it.
Hopefully it can be solved with software  -  and not require a hardware fix/ revision.

[beta-user]

The same thing happens for me on desktop when I unplug the microphone. This has nothing to do with the killswitch and it does not prove that there is something wrong with it.

That is a known "BUG"  I have seen posted for some time  at the Mobian blog site.  It is probably on other operating systems websites as well.
though I did not delve into it.
Hopefully it can be solved with software  -  and not require a hardware fix/ revision.

Is this the bug you are talking about https://gitlab.com/mobian1/issues/-/issues/248 ?

[bcnaz]

YES, that is the one.!

Thanks for that Link.

[wibble]

How are the DIP switches physically wired?  Is there a PCB diagram to prove that they're not just a software trick?

We've got the schematic but no gerbers. Look for sw1-c if you want to see what the mic switch is doing, and how you could verify it. It's meant to physically interrupt the bias power to the mic so you could check continuity when the phone's not powered to see if it operates as advertised. That may not be enough to convince you there isn't a sneaky transistor in parallel that can be used to bypass the physical switch though.

[kqlnut]

We've got the schematic but no gerbers. Look for sw1-c if you want to see what the mic switch is doing, and how you could verify it. It's meant to physically interrupt the bias power to the mic so you could check continuity when the phone's not powered to see if it operates as advertised. That may not be enough to convince you there isn't a sneaky transistor in parallel that can be used to bypass the physical switch though.

I was looking at the schematics regarding the kill switches the other day too and was wondering if cutting the bias would actually prevent the mic from working or just make the input barely audible. Do you know if the bias input is needed for the mic to work at all in the first place?
I have a USB side board which I apparently messed up a bit by trying to resolder the flex cable with the speaker and motor connections. I don't have an explanation what exactly got messed up (I guess something inside the PCB itself because there is no visual damage though that seems strange to me), but one of the symptoms afterwards was barely audible mic input (in addition to a grounded USB data line, also no idea where the ground connection could be located except somehow somewhere inside the PCB). Without removing the mic there are no contact points on which I could check for continuity of the mic bias connection (just the one pin on the connector), but I thought that might be the problem.

[beta-user]

I was looking at the schematics regarding the kill switches the other day too and was wondering if cutting the bias would actually prevent the mic from working or just make the input barely audible.

Shouldn't that be easy to test? Just record the audio with microphone off in audacity and amplify it. Or is it not that easy?

Edit:
I tried blowing air very hard into the microphone and I could actually hear some of it on the recording. So it seems that you were right. I doubt it would be possible to hear words, but I didn't try yelling very hard.