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.
This approach is pretty new, but I’m glad someone suggested it. For karaoke it might seem a bit excessive, but I’m open to suggestions. Thanks to @Lurking for getting things started. If you’re using QJackCtl, you’ll find the “Active Patchbay persistence” setting under Setup>>Options. Turn off the “Replace Connections with Graph button,” then connect your mic, adjust settings, and follow the prompts. Once done, open the Patchbay, click New, accept the snapshot option, save it as an .xml file, and update the Active Patchbay persistence in Setup>>Options. This way, plugging in your mic will automatically route it correctly. If you don’t want to run qjackctl every time, a UDEV rule is the most reliable method. *Graphs work well for clarity, but the “connections bay” is better for those on the simpler side.*
If you prefer a full system patchbay setup, there are other ways that also function, though they’re different. But using a UDEV rule is the safest and most consistent path.
I agree with Patchbay. It can be simpler to test visually, which is why I recommended the a approach. I probably overlooked the follow-up about persistence. I wouldn't have suggested this if KDE had a straightforward tick box like "[x] Microphone passthrough." The contrast is interesting—back then it had a much more functional "sound settings" area under "Settings," and I think it was easy to set up. I’m not sure when the change happened, but it still works. Jack used to be a much bigger pain when PulseAudio was standard, because it wouldn’t integrate smoothly with PA and "jackd" came directly from the "jack-audio-connection" toolkit. Then one device would take full control, and anything else would fail. With Pipewire, "jackd" is essentially just a plugin, and Pipewire handles everything. Honestly, it’s impressive and feels like a long-overdue win for Linux.
A lot of the missing features relate to "alsa capabilities." Honestly, they’ve been cut off from us by this new USB card sound system. Remember, if it existed in the Alsamixer, it should have appeared through its GUI in the sound settings. A dedicated hardware/server/client API stack is something I’m ready to push hard against. *I’d say I’d go all out*, though—this isn’t just a suggestion. I’m genuinely excited about this practical fix for an old problem, and I won’t pretend my HEMA background is anything but solid. Don’t label me crazy, but I’m not hiding from this sensible solution!
It's actually "Schrodinger's sound stack." The main issue with PulseAudio was its default settings trying to dominate everything, and the documentation is really poor. I still use several machines with a PA over Jack over ALSA, focusing on customizing PA to suit your needs rather than following what some developers thought you should do. I keep an eye on pipewire and even maintain a collection of useful configuration examples. Eventually I hope to replace PA entirely, but mastering pipewire will be a much smaller victory than taming PA!
I fully support everything mentioned. I used to steer clear of PulseAudio for a long time. The notion that you need a distinct user-space app just to handle basic audio tasks was a big turnoff for me. Coming from a Debian 3.0 background, where ALSA forced you to craft dmix rules just to play multiple apps at once, things have changed. ALSA improved, and the Open Source community has matured. Over time, PA became more accepted, often resolving issues that once felt insurmountable. I gave it a chance for a while. Still, I keep some doubts about Pipewire, but overall it feels smoother. Talking about adjusting PA to your needs, I recall a time when I switched from trying to dominate devices to simply connecting to Jack as a client. That approach worked better and avoided the need for a separate service. It seems neither method should have been required—especially not running a standalone daemon. Ideally, I’d feel the same about systemd and favor OpenRC whenever possible. Of course, this view might upset some folks.
I've fully embraced a Unix-style approach for this project, recognizing that each component—audio driver, routing server, and client API—must differ to simplify troubleshooting. Alsa performs well as a driver but struggles with routing and API functionality. The routing service, while widely used, depends heavily on Alsa for its driver role, which excels in routing but lacks strong client support. By stripping away redundant features from each layer, the system becomes more efficient (for most users) and the initial setup time is justified by a hassle-free, reliable operation.
I set up Debian instead of Fedora and attempted to rebuild qjackctl. The pipewire packages didn't install properly, possibly due to an error. However, qjackctl functioned, though the graph didn't auto-populate with the microphone details. Later, I discovered Qpwgraph at https://flathub.org/apps/org.rncbc.qpwgraph, which worked well and displayed the microphone connection options clearly.
I managed to observe the microphones on the piewire tab. My voice appeared on the graph in the input section once I added a device. However, I didn’t see any output or hear anything through HDMI. I think I need to look into this more at my desk—my Linux PC is in the living room and I’m using a K400 wireless keyboard with a touchpad. The Qpwgraph still functions and displayed all modules EasyEffect added.