Audio not working after update from fedora 36 > 37

After updating my OS from Fedora 36 => 37 (updated not new install)
The audiodevices have changed name or not found
previous it was something like hw:CARD=Loopback,DEV=0 (Wfview settings)
Not such selection anymore…a lot over others

And in WSJT-X is was previous like plughw:CARD=Loopback_2,DEV=1
No such selection anymore

Original configuration was with Qt audio

On OS basis it seems reporting the same 4 loopback devices and no difference is found in any sound config files.

Using 4 loopback devices because I somet imes run 2 instances of Wfview (IC7610 & IC9700)

Wfview is ver 1.64 build b4c079f, my own build but no change to code

A side observation is that portaudio and Rt audio is resulting in much higher RX latency compared to Qtaudio, also on Fedora 36…is that normal ?

Knud

Sound in Linux is a mess !

Anyway I found the change I have made long ago to /usr/share/alsa/alsa.conf
Which where reversed by the OS upgrade

defaults.namehint.extended off
to
defaults.namehint.extended on

and

defaults.pcm.ipc_perm 0600
to
defaults.pcm.ipc_perm 0660

I’ve now made the change by adding a .asoundrc file to my HOME folder with the changes instead
This will not be overwritten by upgrades

Knud

Good digging, glad you found a simple solution.

—E
de W6EL

Hi Elliott
Any comment on this ?

“A side observation is that portaudio and Rt audio is resulting in much higher RX latency compared to Qtaudio, also on Fedora 36…is that normal ?”

Knud

Every operating system, library, and audio hardware will perform differently. This is why there is a selection of three different audio systems to select from. We could not determine that one was consistently better than the other for everyone.

When you consider the number of operating systems supported, and versions thereof, plus the sheer mass of possible audio products, you see why we left in some flexibility.

As to why, I haven no idea, but I do see sometimes that one system works better than another for me.

–E
de W6EL

just use whatever works best for you.

Now when it comes to updating to F37:

F36 EOL 2023-05-16
F37 EOL 2023-12-05
F38 EOL 2024-05-14 – that’s within one week.

I would suggest to update this eventually soon to a version that’s maintained for a start.
We generally don’t support linux that’s EOL.

That is the challenge with Fedora…they update so often that they break working things which will be fixed close to EOL (maybe first in later releases).
It is more likely that a package can’t keep up with this pace and get broken due to new releases.
In this cases in was not so…I haven forgotten to note down an earlier fix to a problem.
At that time when I found that fix…F36 was a’live and the problem stays even in F39-F40
Loopback devices does not show up in useable way and need this fix.

Knud

my conclusion would then be:

update your setup to something more sustainable better tested environment. I tested wfview on F39 and F40. F39 out of the box and F40 after the update by the way.

Another platform…have taken a approach a few times but ran into other problems and as I have several machines running Fedora it is some what…you know and live with what you have.
But basic you are right about shifting distribution.

Your test on F39-F40…with loopback devices ?
They need the same fix otherwise there are troubles to get Wfview <=> WSJT-X, MSHV, FLdigi…tested
(KDE Desktop)

Knud

Just for the record:

On F39 the wfview package made build downloaded from wfview web page
does not run on F39
“wfview: error while loading shared libraries: libcustomplot.so.2: canot open shared object file: No such file or directory”
qcustom package are of course installed
My own build run’s
I believe that was the reason I way back need to build wfview by myself

Knud

Both built and pre-built. The issue can be solved by just creating a symlink iirc.

Some packages don’t have these mandatory links. Downside of fedora, debian etc.