Microphone broken in Zoom or Signal on Fedora 33

Hi,

I have a problem which started when I upgraded to Fedora 33 (XFCE4). My internal microphone generally works fine. I can record in Audacity, and I can see the microphone responding in Gnome Control Center (Sound).

But for some odd reason, Zoom (zoom-5.8.0.16-1.x86_64) can’t see my microphone. Same with Signal. It worked fine with F32.

The Zoom audio tool doesn’t see the microphone (with any of the available ‘devices’), including the ‘Internal Microphone’, which other tools can see just fine.

[rmm@crank ~] $ rpmq alsa
wine-alsa-6.13-1.fc33.i686
alsa-lib-1.2.4-5.fc33.x86_64
alsa-lib-1.2.4-5.fc33.i686
alsa-sof-firmware-1.6.1-4.fc33.noarch
wine-alsa-6.13-1.fc33.x86_64
alsa-firmware-1.2.4-1.fc33.noarch
alsa-utils-1.2.4-2.fc33.x86_64
balsa-2.6.2-1.fc33.x86_64
alsa-plugins-pulseaudio-1.2.2-4.fc33.i686
alsa-plugins-pulseaudio-1.2.2-4.fc33.x86_64
alsa-tools-firmware-1.2.2-3.fc33.x86_64

xfce4-pulseaudio-plugin-0.4.3-4.fc33.x86_64
pulseaudio-module-x11-14.0-2.fc33.x86_64
pulseaudio-module-bluetooth-14.0-2.fc33.x86_64
pulseaudio-libs-14.0-2.fc33.x86_64
pulseaudio-libs-14.0-2.fc33.i686
pulseaudio-libs-glib2-14.0-2.fc33.x86_64
wine-pulseaudio-6.13-1.fc33.i686
pulseaudio-qpaeq-14.0-2.fc33.x86_64
mpg123-plugins-pulseaudio-1.26.2-2.fc33.x86_64
alsa-plugins-pulseaudio-1.2.2-4.fc33.i686
alsa-plugins-pulseaudio-1.2.2-4.fc33.x86_64
wine-pulseaudio-6.13-1.fc33.x86_64
pulseaudio-utils-14.0-2.fc33.x86_64
pulseaudio-module-jack-14.0-2.fc33.x86_64
pulseaudio-module-lirc-14.0-2.fc33.x86_64
pulseaudio-libs-devel-14.0-2.fc33.x86_64
pulseaudio-module-gconf-14.0-2.fc33.x86_64
pulseaudio-module-zeroconf-14.0-2.fc33.x86_64
pulseaudio-14.0-2.fc33.x86_64

For some reason, some pipewire modules are installed, but pipewire is not running. I wonder if Pipewire is getting in the way of my mic somehow (for certain applications)… Romoving just the pipewire package necessitates removing 50 other packages, so I left it installed.

[rmm@crank ~] $ rpmq pipewire
pipewire-0.3.26-2.fc33.x86_64
pipewire0.2-libs-0.2.7-4.fc33.x86_64
pipewire-libs-0.3.26-2.fc33.x86_64
pipewire-gstreamer-0.3.26-2.fc33.x86_64

[rmm@crank ~] $ uname -a
Linux crank.gvdig.com 5.14.12-100.fc33.x86_64 #1 SMP Wed Oct 13 15:09:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[rmm@crank ~] $ inxi -A
Audio:
Device-1: Intel 100 Series/C230 Series Family HD Audio driver: snd_hda_intel
Device-2: Logitech HD Pro Webcam C920 type: USB driver: snd-usb-audio,uvcvideo
Sound Server-1: ALSA v: k5.14.12-100.fc33.x86_64 running: yes
Sound Server-2: PulseAudio v: 14.0-rebootstrapped running: yes

[rmm@crank ~] $ dmesg|grep snd
[ 9.245874] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
[ 9.245891] snd_hda_intel 0000:00:1f.3: enabling device (0000 → 0002)
[ 9.466302] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 9.501384] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3266: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
[ 9.501389] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 9.501391] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[ 9.501392] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0
[ 9.501393] snd_hda_codec_realtek hdaudioC0D0: inputs:
[ 9.501394] snd_hda_codec_realtek hdaudioC0D0: Headset Mic=0x18
[ 9.501395] snd_hda_codec_realtek hdaudioC0D0: Headphone Mic=0x1a
[ 9.501396] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12
[ 10.810098] snd_hda_codec_hdmi hdaudioC0D2: Monitor plugged-in, Failed to power up codec ret=[-13]
[ 10.880098] usbcore: registered new interface driver snd-usb-audio
[64760.046551] snd_hda_intel 0000:00:1f.3: Unstable LPIB (352800 >= 176400); disabling LPIB delay counting
[257783.211394] snd_hda_codec_hdmi hdaudioC0D2: Monitor plugged-in, Failed to power up codec ret=[-13]
[257784.213425] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x205f0015
[257784.213437] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x205f0015
[257784.213443] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x205f0015
[257784.213448] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x205f0015
[257784.213452] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x205f0015
[257784.213456] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x205f0015
[257784.213459] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x205f0015
[257784.213462] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x205f0015
[257784.213465] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x205f0015
[257784.213469] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x205f0015
[257784.213472] snd_hda_intel 0000:00:1f.3: spurious response 0x0:0x2, last cmd=0x205f0015
[257785.214413] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x20570100
[257786.215402] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x20570100

!!Sound Servers on this system
!!----------------------------

PipeWire:
Installed - Yes (/usr/bin/pipewire)
Running - No

Pulseaudio:
Installed - Yes (/usr/bin/pulseaudio)
Running - Yes

aRts:
Installed - Yes (/usr/bin/artsd)
Running - No

Jack:
Installed - Yes (/usr/bin/jackd)
Running - No

Any ideas for how to get my microphone back in Zoom?

Thanks!
Richard

http://alsa-project.org/db/?f=ef91214b03916116866adcd5165348bab3557532

Did you select the appropriate mic in the gnome → settings → sound control panel? I see 3 different mic entries in the inxi output above.

I hope you realize that fedora 33 will reach EOL in just over 1 month.

Yes, I tried all options. Nothing works in Zoom. The ‘Intermal Audio’ is the option which works in other applications, and should work in Zoom. This would be the built-in microphone on my laptop…and has always worked in the past. and works in Audacity, arecord, Gnome applications, etc.

It’s like there’s something in Zoom, and Signal which maybe ‘sees’ that pipewire is installed, and assumes that he interface to use? But it’s not… I’m hoping that there’s a text file I can efit to set Zoom straight…

Thanks, I knew it was coming, and it seems Fedora 34 is even worse, audio-wise (for application support), due to a new audio framework (Pipewire). I suspect this issue is implicated in my microphone woes. I really wish Linux would get a clue, and try to keep systems backward-compatible… It’s audio…not rocket science. Nothing has changed in that department in 30 years. We just want it to work! Sheesh! Stop messing with it!

Fedora 32 to F34 solved my audio problems.

With pipe-wire Linux got lifted from hobby-audio to pro-audio. Just make you a F35 live usb and test it. !m sure it will work out of the box.

Ok, i believe you that you will have troubles if your hardware is 30 years old :joy:

Ha! I just find it funny that over the close to 30 yrs I’ve been running Linux, the audio system has continually been a moving target, and thus has always been fickle, regardless of the flavor of Linux. The HW, buses, and drivers have changed, but at the end of the day, it’s just audio, and there have been no earth-shattering advancements in like forever. A Soundblaster Pro from back in the day performed pretty much the same as what we have today.

I’m just frustrated (and whining…) with the ‘hobby mentality’ of Linux. I want it kill OSX and Windoze, and make it a no-brainer for my kids to learn and adopt (and the people I work with too). But they need to get things done (like me), and the constant state of brokenness and fickle aspect of video/audio makes it a hard sell. I do think it will assimilate Windows in the near future… Maybe then developers will prioritize robustness over eye-candy, or whatever. Oh crap, curmudgeon alert!!!

I could maybe try F35. I have lots of things to keep going (compiler support, FPGA dev tools, simulators, etc), and staying at the bleeding edge is not a good place for me to live. But I don’t necessarily like the long-term support version either, as new stuff I want to try doesn’t work. So I’ve found that being somewhere in the middle works well for me…usually…as long as someone doesn’t break stuff, like what I’m dealing with now…

Exactly, unfortunately drivers and hardware hav been closed source, and Linux has been treated as a “Foster Kid”. Fortunately this changed much since.

You don’t have too , we have been teens when we got involved. Their born with this tech and got involved with Linux from beginning on. Soon they will teach us because they have access to an open environment we not had.

Back on topic:

I bought me a docking station for 2 external hot swap-able HD’s, where I could test parallel to my daily OS, fedora 34, with all this new things. This might be a way for you too. A USB to SATA cable also does the job.

When everything works as you need, you just swap the Internal with the external HD an everything is as it was before, except that your audio finally works :bluethumb: :fedora:

1 Like

“With pipe-wire Linux got lifted from hobby-audio to pro-audio”

Not really.

Linux still uses ALSA which in turn still uses the S/PDIF protocol which in turn:

  1. was last updated around 2003

  2. was designed for coaxial and composite RCA connectors

  3. only allows uncompressed audio on 2 of 8 channels, whereas HDMI audio allows uncompressed on all 8. With HDMI a professional audio engineer is able to do post-recording editing on all data without any loss of information, whereas some information is lost on the 6 S/PDIF compressed channels. Also great for remastering.

ALSA also employs the AC-3 protocol from Dolby, which:

  1. was deprecated in 2012 by Dolby for AC-4

  2. also requires compression with data loss, thus professional sound engineers do not have full control of the sound.

I doubt pro audio engineers will adopt Linux anytime soon.

For hobbyists, there are still many working online on projects to get proper HDMI sound from their various Linux OSes, with variable success.

Going through the logs of the ALSA group my impression is its interest in HDMI seems to have petered-out a few years after HDMI was introduced. The last log entry was something to the effect of “it will be hard”.

HDMI audio just plain out-performs Dolby and DTS.