I've been experiencing issues using my microphone in electron apps for the past couple of weeks. When trying to call others in Slack, Wire, or using Google Hangouts through Chrome no one was ever able to hear me. Checking in the GNOME settings panel I could see that the system was reading the input from my microphone. However, this signal seemed not to be getting through to the electron apps. (I tried recording a video through GNOME cheese and was able to hear the input from the microphone.) So finally this morning I decided to dig through my system configuration and I tracked the issue down to PulseAudio. Although the volume of my microphone was set correctly in the default settings, I saw that when I started up a call, Pulse Audio had set the input stream volume to the application to 0. (In pavucontrol this can be seen in the "recording section.") By dragging the slider up from 0, I was finally able see that the electron apps were getting the microphone signal. I'm unsure if this is an issue with electron incorrectly setting the stream volume or if this is an issue with our configuration in Solus. I've experienced this issue on two separate machines running Solus so I don't think it is a hardware issue but I'd be interested to know, has anyone else has experienced this issue?
Description
Event Timeline
Same issue here. If you need any help with testing or finding a solution, let us know what we can help with.
I experienced this issue on both a Dell XPS 15 and 13 which have HDA-Intel integrated sound cards.
@alecbcs , @feuerstein , is this still an issue? It has been a long time since there was an update to this task, and there have been many updates since this issue was opened. Thanks.
@TClark77 I stopped using Solus a number of years ago due to a few of these bugs. I don't know if it is still prevalent in the modern version of the distribution. If you have access to an HDA-Intel card you might be able to test if you can open up Element or Slack and attempt a video call.
I have been able to connect to calls in Element with my bluetooth earbuds without experiencing this particular issue. I've experienced a slightly different, maybe similar issue with pipewire on Plasma.
Steps to reproduce:
- Connect to bluetooth earbuds
- Use the system tray sound icon to choose the "handsfree" setting for the earbuds rather than high-fidelity (handsfree allows both mic input and audio output)
- Start Element
- Join a call
The mic input was fine, but the output volume is at 0% in the system tray volume applet. I have to manually set the output volume to something above 0% every time I have a call.
❯ more /proc/asound/cards
0 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0x628d1d8000 irq 173
1 [NVidia ]: HDA-Intel - HDA NVidia
HDA NVidia at 0xaa000000 irq 17
2 [Wireless ]: USB-Audio - Arctis Pro Wireless
SteelSeries Arctis Pro Wireless at usb-0000:05:00.0-2.2.2.3, full speedWhen you are just listening to audio Pipewire is negotiating to use the best-sounding audio codec that your hardware supports (preferably LDAC or AptX HD of the ones that our Pipewire supports, though AAC is not too bad). These codecs sound decent but have poor latency. When you join a call using a bluetooth device with an integrated microphone then Pipewire automatically switches over to a codec with low latency (but generally poor audio quality).
It is not surprising that Pipewire saves the volume separately for these as a user probably wants this. It is surprising that you have to keep resetting from 0% every time you have a call though.