Wireless microphone picked up in Fedora 42 KDE, causing the bar to move without any audio output.
Wireless microphone picked up in Fedora 42 KDE, causing the bar to move without any audio output.
I've just set up Fedore 42 with KDE and everything functions properly from the PC side (YT). All updates are current. I connected a wireless USB microphone, Behringer ULM200D, and Fedora recognized it. When I sing into it, the microphone icon near the speaker changes noticeably (highlighted). The PC receives the signal, but no audio comes through HDMI. Even at maximum volume (150%), the bar stays still in system settings. For the mic, I have analog, Pro Audio, and digital input options. Both Pro Audio and digital input behave similarly—bar moves clearly. Google suggested installing pavucontrol. I think I installed it correctly, and the bar still moves under the input tab when speaking. However, with pavucontrol, the bottom-right sound settings no longer show movement. Google also recommended reinstalling pipeweire: sudo dnf reinstall pipewire pipewire-pulseaudio pipewire-alsa wireplumber. I did that and restarted the system. I checked Behringer's website for drivers or alternatives, but they don't have any, even for Windows. I want to emphasize I'm using KDE, as settings seem very different from Gnome. What else could I try?
Hmm, you were hoping to hear your microphone through the default output? Let's think about it. It would likely cause a feedback loop, which isn't enabled by default on any operating system. To record, try using Audacity. If you're unsure how to test compatibility with your VoIP app—like Discord—just let me know, and I can guide you through it.
I prefer not to record anything. I just watch a YouTube video in the browser with karaoke music, then someone sings and the PC blends it with the original sound, sending both through the output (like HDMI). This is how it functions in Windows—though not by default, but you can adjust it in one of the less obvious sound settings under W11. In W11 I’m not using any particular program. Be mindful of volume levels to prevent feedback, but it works as expected. What adjustments should I make? Since the PC receives the audio signal (the microphone input), I thought changing a simple setting would direct the signal to the output. If installing a mixing tool is necessary, that’s okay too; Gemini suggests pavucontrol, but it doesn’t seem to handle this directly. I didn’t want to run random commands or install software that Google recommends.
The microphone slider can be misleading (oh, Linux world). It doesn’t control the actual volume through your speakers, but rather the overall sensitivity or “gain” of the mic. The closest Windows option is the hidden “Mic Boost” slider that adjusts in small increments of +0/10/20dB. Pavucontrol offers similar functionality with minimal changes, so you might skip it. “Pro Audio” isn’t particularly useful to me either—I haven’t found a purpose for it. You may want to try Jack and QJackctl instead. It’s not intuitive at first, but the “Graph” window lets you connect different audio devices as you would with traditional cables, which is why it’s named that. You might need to keep it in “stopped” mode when making adjustments. I use an audio interface for instruments, but have a comparable system for other projects and for listening back on my headphones. I’m not sure how well it will work just with the PC’s sound card, but it seems possible. To get started, you’ll need these packages: pipewire, pipewire-jack-audio-connection-kit, pipewire-pulseaudio, qjackctl, wireplumber. If you install “qjackctl,” it will likely pull in most of the dependencies already.
Apologies for the misunderstanding. It turns out you're dealing with a karaoke setup. When I need to play my microphone, I usually run ffplay from the terminal: ffplay -f alsa -i default -vn -probesize 32 -analyzeduration 0 -fflags nobuffer. Pulse can be an alternative, but PulseAudio depends on ALSA, which may add extra delay. This could cause latency issues, though there are ways to minimize it. Check the settings and see if it meets your needs. If not, consider the approach @NoLeafClover recommended.
I managed to complete that in the graph. Just needed to connect wires from the microhome to the "built-in digital Stereo..." and it functioned properly! How do I make it last through a restart? The same applies when I disconnect the USB dongle—only plug it in when I need the microphone, so it lasts longer. If I have to redraw it before a karaoke night, it’s not too big of an issue. But for the rest of the family, they’re quite upset since they rely on it. I installed it and ran that command, but it kept running for over 30 minutes counting numbers before I had to restart again.
It shouldn't take long now. A small waveform window appeared. Anything visible on it? While you spoke or sang. The only thought I have is the default setting—your screenshot shows the microphone as the default. From what you showed, it seems to be the built-in one. You mentioned using Jack already, but if you still want to investigate, try manually selecting the input: arecord - l. In my case (on a laptop): card 1 - built-in mic card 2 - wireless headset via USB dongle. To hear the built-in mic, use ffplay - f alsa - i hw : 1 with vn, probesize 32, analyzeduration 0, fflags nobuffer. The waveform looks like noise, no background sound, no filtering. For the headset mic, add -channels 1 because it's mono: ffplay - f alsa - i hw : 2 with vn, probesize 32, analyzeduration 0, fflags nobuffer, channels 1. Lower volume but much clearer.
The extended pause was just a countdown in the terminal. I didn’t see a visible window showing the program status. Do you need to execute those commands each time you connect and start using the microphone?
This isn't a major issue, if it all. PulseAudio, as far as the original PulseAudio goes, is... "dead". Unless there's significant compatibility issues, nobody these days should be using the "pulseaudio" package. Pipewire is newer and has been designed to overcome many of the issues with PulseAudio, including being able to act as a single "media graph" tool to bridge inputs/outputs across multiple protocols. It thus also acts as a drop-in replacement for the pulse daemon for applications that want to use the "pulse" protocol. There is no reason to have PulseAudio present, but some pulseaudio packages, e.g. "pulseaudio-libs", "pulseaudio-utils" are still okay to have and may even be pulled/already present as dependencies of other packages (e.g. KDE). They provide the PulseAudio API integration, not the actual implementation, which will be handled by Pipewire. The latency with Jack is minimal, and can be configured to run as a real-time process. This is exactly what it has been designed to do, other than the input/output wiring. When I use it with musical instruments most of the latency actually comes from how the audio interface itself is configured (sampling frequency, buffer size, etc), and other applications (i.e. effects) in the audio processing chain. Even then, I often have it in under 2 msec end-to-end - completely imperceptible for non-professional uses. ALSA will, naturally, work, but there are still occasions where it can take exclusive hold of device/s. This can sometimes be an issue for anything else that might want to deal with sound. In any case, for OP's use-case any significant latency will largely be determined by the audio card. Both approaches are workable, so OP should choose whatever is easiest. I personally would not recommend directly interfacing with ALSA. You would need to keep "ffplay" running in the background, yes.
Yes, but only when I want to test my own mic, which is uncommon: just during troubleshooting (no karaoke parties at home). My mic mainly runs for Zoom, Meet, Discord, etc., where it's not required. I don't type the full command—my alias 'monmic' is in my shell config, and I used to have a shortcut file, but I removed it since I don’t use it much. Closing the window also halts the command. For your karaoke needs, you’d need ffplay running, and if you want it to start automatically on login, add it to KDE’s autostart or set up a systemd service. If you need it constantly, consider using jack instead.