[EDIT: this was my mistake. After further testing, I saw that the problem was with my earbuds rerouting the sound from output to input.]
I was on a Signal call (video + mic connected to Signal VM + headphones). Signal is in its own VM.
My Signal call was ongoing when I launched a Zoom conference in a separate Disposable VM. Suddenly, everyone on the Signal call stopped talking. Because they heard the people from the Zoom call coming in from the Disposable VM! So the sounds from the Zoom VM entered the Signal call in the Signal VM!
Hi @sven. It’s not possible. The sound was loud and clear far beyond what can a mic pick up from earbuds (sorry - they were in-ear earbuds. not headphones. I mix up these two.). I’m ready to test it with someone who can be on the receiving end of a Signal call and record my screen - to replicate what happened.
@sven, i’m sorry. I just tested it again and it turned out that the earbuds were the problem. They were rerouting the sound - and not just the mic picking up the sound. Something is wrong with the earbuds.
I recommend this threat to be deleted. It was my mistake!
I just tested it again and it turned out that the earbuds were the problem. They were rerouting the sound - and not just the mic picking up the sound. Something is wrong with the earbuds.
Wait… how is that possible for a pair of earbuds to reroute sound in isolated VMs on your machine? Can you please describe in more detail?
I have a messaging app that allows me to select “default” or “Qubes VCHAN source” for the microphone. If I select the VCHAN source and the microphone is connected to that VM (using the tray gui), I assume it’s ready to go (dom0 makes the mic available to the VM and the app setting gives the app permission to use it in that VM).
But does connecting the microphone to the VM make the it available to the entire VM or just apps that are explicitly permissioned to use it?
And for the sake of clarity, if the mic is not connected to any VM by dom0, can I assume the mic is not recording or tranmitting audio anywhere? I ask because the audio mixer in the tray has levels for devices and applications. If those levels are up but dom0 hasn’t connected the mic to any VM, can audio somehow leak?
Many machines have a combined headphones/mic port.
Typically (stereo) headphones contain three conductors called tip, ring, and sleeve, which map to left signal, right signal and ground (i do not recall the order).
A headphone jack that also incorporates the mic input, such as is found on many laptops, would expect a plug with tip/ring/ring/sleeve for mic signal, left signal, right signal, and ground (again, i do not recall the order).
It’s possible that some combination of headphone+mic accessory or headphone accessory plugged into a combo headphone+mic port might misalign** or misconnect** signals such that one or both output channels (left or right) might be touching the input (mic) channel.
Brendan
** this could be due to incomplete plugging, bad plug/jack design, or poor construction tolerances of said plug or jack.
That doesn’t make sense to me because crossed hardware wires or not, they are still handled by Xen which is managed by dom0 which delegates connectivity to specific VMs. I don’t understand how crossed channels would start sending signals to different VMs without dom0 giving the okay.
Even if the microphone line was inadvertently connected to a speaker channel, wouldn’t that cause the mic to function as a speaker before it would send mic access to an alternate VM?
As a side note, it does make the Librem that much nicer to have the option of the mic kill switch.
I agree with @necker in the sense that the solution the OP picked deserves a bit more detail.
@oijawyuh can you explain what you mean by “[earbuds] were rerouting the sound” ?
Especially what you mean by “rerouting”, as the common earbuds are just pieces of plastic with no special ability to “route” data packages or anything.
Thank you @adw for your reply. I am familiar with the deletion policy because I was the one who deleted a post which started the conversation which led to the deletion policy
I tested again. I confirm that relatively cheap earbuds w/ microphone are indeed “rerouting” or re-transmitting sound from Audio Output into mic-in and feeding into the VM where the mic is connected.
If I remove the problematic earbuds from the jack, the sounds stops transmitting from DipsVM to Signal VM.
I tested with another pair of earbuds and microphones (more expensive; high-end samsung) and the problem did not occur.
Please bear with me… I would really like to understand what happened to your system.
Are you sure the ear buds are faulty? They have a TRRS connection, so they are always trying to send a mic signal through the port.
What are your audio settings? You said you had a zoom call in one VM and a signal call in another. What microphone were you using for those comms (internal or external)? Which VMs did dom0 connect the microphone?
If you were zooming in one VM and signalling in another, did you have the mic connected to both but muted in one? Was the mute somehow unmuted from the insertion of the TRRS plug?
Were you using the internal mic for your comms and the insertion of the external mic automatically switched the audio to the external mic source?
My audio settings are default. I didn’t touch anything, other than connecting the mic and cam to the Signal VM (Debian minimal). Mic can and was only be connected to one VM.
DispVM is based on Fedora 34 and has the Zoom video and Firefox where I played YouTube, that send the sounds to Signal.
The built-in mic of Carbon X1 Gen8 does not work with Qubes 4.0.4. I only used the external/connected mic. Internal mic does not pick up any sound.
My assumption is that the earphones are faulty.
I hope this helps. I will try to answer to the best of my abilities.
@oijawyuh I really appreciate your replies. I still don’t understand the mechanism in which a faulty TRRS plug could jump virtual domains. Maybe someone with experience in this area has some ideas?
Assuming my interpretation of first post is correct…
Domain A has an current phone call going, so audio out and mic in are both live for domain A, routed to a mic-equipped headset on the user.
Domain B has an incoming call that is answered. In Qubes, no mic is attached to domain B. Audio from incoming domain B call is also routed to output (that is, to headset).
User can hear audio from both domains, which is expected.
However, with the faulty headset, somehow some audio routed to the earphones is looping back into the mic output of the headset, so parties on the call in Domain A can hear parties on the call in Domain B speaking.**
This could be a physical issue with the alignment of the T/R/R/S plug, or it could be due to improper isolation of the mic signal (e.g. missing filter components), since output (audio to ear) and input (audio from mouth) all share the same ground pin.
Brendan
** it’s likely that there may have been some echo in Domain A as well, before the second call came in, due to the same hardware issue.
I’ve seen a few cases of the headphone audio bleeding into the mic cable via crosstalk. Not much one can do if that is the issue except replace finnicky fragile cables.
The crosstalk problem appears to be an electrical design issue of the “common audio ground” of the mic and speaker jacks. Connecting an amplifier speaker to the headphone jack seem to not cause the crosstalk, its only headphones. The solution is to separate the grounds for the two connectors. I resolved it by running a separate ground wire from the rear pc stereo output jack’s sleeve, by looping it around the speaker jack end, to the headphone jack’s ground; as suggested in this question: microphone - PC Headset crosstalk - Electrical Engineering Stack Exchange
I spent 2-3 minutes on this. I am sure you can find more examples and details using the search engine of your choice.
I note one thing. There was absolutely no echo when this first occurred. Only the sound from the DispVM (Zoom, YouTube, isolated) was reentering. The sound coming out from my Signal VM did not route back, and the 3 people I was chatting with did not hear their voices back. Very puzzling.
But I guess I just need to get some better headphones.
Hmm, this would seem to contradict my hypothesis unless something else mitigated the issue for one set of signals but not another. E.g. perhaps L/R output was mono in all cases…but out-of-phase in VM A (cancelling out the interference to the mic)…and in-phase in VM B (interfering with the mic).
Anyway, if it depends upon the VM types, then maybe there is some sort of pulseaudio loop happening.
