The problem: When you log in, Gnome picks whatever it damn pleases to make the active audio device(s). In my situation this was a little used but electrically problematic (bad grounding caused it to introduce an annoying hum) Dell Sound Bar. I fiddled with the gui interfaces (both Gnome's built-in and the add-on pavucontrol), with no success.
NOTE: No longer using this as I've moved on to Ubuntu 22.04 with pipewire. I'm back to working with pavucontrol to try keeping things under control.
Some brief notes to bring together what I've personally found to work.
The definitive thread on askubuntu is here:
https://askubuntu.com/questions/1038490/how-do-you-set-a-default-audio-output-device-in-ubuntu-18-04
This contains the answer(s), but in a disjointed way.
Here's what worked for me:
- Get the names of your audio devices loading by running
pactl list short sinks(for me this would includealsa_output.pci-0000_00_1f.3.analog-stereo, my built-in audio). - Create a new command with Startup Applications called "Set Default Audio Output" and
enter this as the Command:
pactl set-default-sink <device name>. In my case:
pactl set-default-sink alsa_output.pci-0000_00_1f.3.analog-stereo
- Save and exit Startup Applications and log out.
- Log back in and verify that your desired audio device is now active (Gnome settings sound applet or pavucontrol will show this).
While normally I'd prefer to run something like this from .bashrc or .profile, I opted for a Startup Applications command because it launches with Gnome, and so won't get bigfooted by whatever settings the damned gui decides to impose.
As I was going through this exercise, I couldn't help but think I'd been through this kind of struggle with an operating environment before. Then I remembered. Right. Windows 95 (and every Windows since).
NOTE: The favoritism shown by PulseAudio to USB audio devices is no mystery. That's driven, among other things, by line 37 in the default /etc/pulse/default.pa (the whole section in context):
35 ### Use hot-plugged devices like Bluetooth or USB automatically (LP: #1702794)
36 .ifexists module-switch-on-connect.so
37 load-module module-switch-on-connect
38 .endif
Anyone trying to control Pulse's behavior at the system, rather than user, level should comment that line out. For user level fixes like the one above it can be left in place (which is a relief because changes there could be overwritten by future updates).
NOTE: If you're thinking about doing PCI passthrough with an Intel CPU having onboard graphics (e.g. HD530 on a 6th generation i5 or i7) you'll most likely have to blacklist the i915 module. Doing that may also make the onboard audio inaccessible on boot, mooting the above trick. You'll probably be able to switch to onboard audio after logging in, but that might compromise your ability to passthrough GPU. As always, YMMV. The results I observered were on a 3 year-old i5-6500 in an Asus PRIME B250M-C/CSM. And no, I ultimately wasn't able to get passthrough to work for... reasons.
Re prioritizing internal mic over 3.5 mm earphone mic. You may not be able to. On my X250 laptop, plugging earbuds with a built-in mic into the 3.5 mm jack automatically shuts off the internal mic. It seems that behavior is baked into the hardware. Since the internal mic for the X250 is more horrible sounding than a typical cheap earbud mic, I now use a tiny external usb sound card (https://amzn.to/3BH2N7K) between an earbud mic and the computer. The sound is noticeably better (probably because noise reduction actually works now). This wiki article is about the best out there on configuring PulseAudio, so you may want to look at it: "PulseAudio". ArchLinux Wiki. https://wiki.archlinux.org/title/PulseAudio, and the companion article on "Troubleshooting", https://wiki.archlinux.org/title/PulseAudio/Troubleshooting. Also take a look at your computer hardware manual and any forums specific to that hardware.