Verified as having no issues on MacOS or Windows 11.

Merged. Thanks!

Ok, something about this kills my audio on my system. No audio in the waterfall, and no decodes. The AppImage from PR #199 works fine, the AppImage from this PR does not.

Hmmm. Do you get the "Requested output audio format is not valid" error on startup? If you go to the configuration and choose your input again in the dropdown and save, does it start working again? What platform are you running on?

I never got the audio format is not valid before, and still don't get it with this patch.

I've switch back and forth from the cpu audio jacks and my headset. I get WF stuff when the headset is selected.

OS : Ubuntu 24.04 kernel 6.17.0-14-generic
CPU: AMD Ryzen 9 9950X

This patch

Previous PR

@wmiler OK, can you try something?

First try to add src->reset() after src->stop() in SoundInput::canOpenAsInput.

Like this:

bool SoundInput::canOpenAsInput(const QAudioDevice &dev) {
    QAudioFormat fmt = dev.preferredFormat();
    auto src = std::make_unique<QAudioSource>(dev, fmt);
    src->start(); // opens device
    src->stop();
    src->reset(); // <-- Add this
    return src->error() == QAudio::NoError;
}

If that does not solve the problem, just make SoundInput::canOpenAsInput return true and see if that works.

If neither of these things work, we can either remove the check altogether, it's a belt-and-suspenders thing, or revert this patch and people like me with janky Linux audio setups can just deal with resetting the input every time we open the app.

Ok doing the reset() didn't seem to do anything.

Setting it to return true, gave me this:

Which obviously isn't right.

OK, I think I see what's happening, and why the code was the way it was. That's a bummer, we'll just have to back this one out.

It doesn't make sense to me as to why this would work on one linux brand, but not another?

My hypothesis is that there is a whole class of problems that result from audio devices not being correctly reported to QT as either inputs or outputs. On my system, the input device for my FT-DX10 is correctly reported to QT as an input in the call to QMediaDevices::audioInputs(), but the "mode" that's reported for it is incorrectly set to output. Since we check to make sure that the configured input has its mode set to input, my device fails that test, and I get the "format is not valid" error, and I don't get waterfall activity until I open the config and re-select the input. So on my system, replacing that string check with a check to see if we can actually open the device as an input solves the problem. However on Wyatt's system, it sounds like he has a different but related problem. I can't tell exactly what's happening there, but it looks like a case of outputs with monitor sources being reported/used as inputs.

The bottom line is that Linux Audio is a horror show, and we're not going to be able to fix that.

My hypothesis is that there is a whole class of problems that result from audio devices not being correctly reported to QT as either inputs or outputs. On my system, the input device for my FT-DX10 is correctly reported to QT as an input in the call to QMediaDevices::audioInputs(), but the "mode" that's reported for it is incorrectly set to output. Since we check to make sure that the configured input has its mode set to input, my device fails that test, and I get the "format is not valid" error, and I don't get waterfall activity until I open the config and re-select the input. So on my system, replacing that string check with a check to see if we can actually open the device as an input solves the problem.

So did just a bit of research on this, and found a whole bunch of QTBUGS related to the issue.

However on Wyatt's system, it sounds like he has a different but related problem. I can't tell exactly what's happening there, but it looks like a case of outputs with monitor sources being reported/used as inputs.

That seems to be the jest of what I have read as part of the issue.

The bottom line is that Linux Audio is a horror show, and we're not going to be able to fix that.

Agreed. I doubt it will be resolved any time soon. ALSA/Pipewire/PulseAudio. Any bets on who wins? BetaMax or VHS? ;)

I had understood that Pipewire was supposed to be the audio transport layer on linux that mimics MacOS's CoreAudio or Windows' WASAPI. It's possible it's not mature enough yet to sort out these issues. The Qt guys complain because linux is the only one that implements drivers in kernel space, the other two can implement drivers in userspace as extensible runtime modules, and this does sort of appear to be a driver-related issue.

I'm not even really sure where the problem lies. Since PulseAudio automatically gives all sinks a source, the very concept of what inputs and outputs even are is squishy. Since it's common for I/O devices to use the same name for both, you end up with two inputs with the same name, but only one is the actual input, the other is a wire tap of the output. Since we only store the name of the device, there is an opportunity for confusion. Maybe we could avoid that if we stored a hash of all of the device details instead of or in addition to just the name? I'm not sure how volatile that could be though.

@rruchte I think the linux folks need to come up with a way to implement drivers on-the-fly in userspace vs relying on the ALSA back end that is hard-wired into the linux kernel. Both Pulseaudio and Pipewire are merely servers running on top of ALSA. I think it's just that linux developers have not done anything about it because of the design of the kernel.

While Linux is not Unix, it is a copy of it. MacOS is a true Unix system but it implements drivers completely differently with CoreAudio. The USB Audio CODEC thing is broken down into valid input and output channels by the drivers for it, even though it has the same name, the MacOS drivers enumerate it into what can be used for I/O, and the system automatically selects it.

I can even plug in my iPhone and use it as the mic for JS8Call

This is because of drivers that allow this. And no linux developers have ever dove into it to fix the issue because ALSA and the kernel drivers are too entrenched in the ecosystem. So you get screaming and gnashing of teeth from Torvalds and the kernel crew if you try to bypass it because ASLA is the One True Way.

But that doesn't mean some developers willing to go against the grain can't fix it. Due to Torvalds' design, the linux kernel has become horribly bloated with all the driver "modules" stuck into it for modern desktop systems. This has been known for years, yet nobody actually fixes it:
https://www.crn.com/news/applications-os/220100662/torvalds-calls-linux-kernel-huge-and-bloated

Where the Qt folks are concerned, they said to heck with all this - we're not supporting it anymore because it is a poor design. They said we'll go with Pipewire, and if that's not available fall back on Pulseaudio, the linux developers are going to have to figure out how to tie it to the ALSA back end. The way I see it, the linux developers COULD turn Pipewire into the same thing as CoreAudio on Mac where you can implement audio device drivers on-the-fly with a simple library that is loaded at runtime. They just haven't done it yet.