I’ve been using Debian since 2000 (potato).
I’ve occasionally had to use other distros for work (Red Hat or Ubuntu, typically), or to verify/troubleshoot bugs reports in upstream packages.
But my preference is Debian all the way, for servers or workstations.
It’s stable, and it has a great community. Also ideologically speaking, it has the Debian Social Contract and Debian Free Software Guidelines.
Ah, ok. I guess I misunderstood.
I’m afraid I don’t have any other suggestions that haven’t already been made elsewhere in the thread.
Best of luck, and I hope you get it figured out.
Shot in the dark here…
You said that blacklisting the module brought back your device, but not the sound. Is it possible that pulse is selecting the dummy as the default interface?
Before reloading alsa and restarting pulse - If you go into pavucontrol and change the input/output devices to your sound card, does the sound start working?
If that’s the case, then you should be able to edit your pulse config to force your audio device to be default, regardless of whether or not the dummy is present.
(No idea about the dummy device, sorry)
Back in the 90s, Windows NT had a POSIX compatibility layer that you could enable (it wasn’t enabled by default).
I have sort of had enough of copy and pasting commands I find on the internet without having a good understanding of how they actually work.
One thing you could do is start trying to understand those commands.
Read the man pages or the documentation to figure out what the commands are actually doing. Once you have the “what” , you can dig deeper to get to the “why” if it isn’t obvious by that point.
After enough of that, you’ll go to copy/paste and already understand what it’s doing without needing to look it up again.
Then from there, it’s a matter of building the instinct to be able to say “I need to do X, so I’ll use commands Y and Z.”
This pic made me smile.
I haven’t been to DebConf since before COVID, but I definitely recognize a few people in that pic.