I have a notebook (AMD chips) connected to a hub (via USB-C), with two monitors hooked up to the hub (via HDMI). The monitors have built-in speakers, and I use one monitor's speakers for default audio. I'm running Fedora 35 MATE desktop (with Pipewire). The problem is that which monitor's speakers are which flips around.
Right now, the main monitor is "Renoir Radeon High Definition Audio Controller HDMI / DisplayPort 1 Output" and the second monitor is "<same> 4 Output". After a suspend/resume cycle though, they randomly swap, so I have to go into Sound Preferences and change the default output device.
The video side always keeps the correct monitor mapped as the correct part of the display layout, so it seems either there's a unique ID or something that keeps them in the right order. Is there something similar to keep it right for audio?
On Mon, 25 Jul 2022 08:03:46 -0500 Chris Adams linux@cmadams.net wrote:
I have a notebook (AMD chips) connected to a hub (via USB-C), with two monitors hooked up to the hub (via HDMI). The monitors have built-in speakers, and I use one monitor's speakers for default audio. I'm running Fedora 35 MATE desktop (with Pipewire). The problem is that which monitor's speakers are which flips around.
I think this is a consequence of parallel boot. The order in which devices are discovered is non-deterministic.
Right now, the main monitor is "Renoir Radeon High Definition Audio Controller HDMI / DisplayPort 1 Output" and the second monitor is "<same> 4 Output". After a suspend/resume cycle though, they randomly swap, so I have to go into Sound Preferences and change the default output device.
I would guess that these monitors have the same sound hardware? Use aplay -l to check if there are two identical devices available. It sounds (heh) like pipewire is just using the device that ends up in whatever slot it considers default.
The video side always keeps the correct monitor mapped as the correct part of the display layout, so it seems either there's a unique ID or something that keeps them in the right order. Is there something similar to keep it right for audio?
Not sure how video works, probably it is discriminating based on the connection. But audio is determined by alsa as it discovers sound devices. It has been a long time since I investigated this, but I think it is still possible to assign specific slots to devices using a script in /etc/modprobe.d. Something like the one at this link: https://gist.github.com/andering/801eb7fe79520036dff4a90340fac7f6 Unfortunately, my experience has been that the audio hardware on graphics devices tend to ignore this because the video starts before the other audio devices, and so always gets slot 0, the default sound device position. But, you can try assigning names to the devices as the above file demonstrates, and then assigning them positions, and then setting that position as default. Since your competing audio devices are both graphics device based, it might work. And it almost surely will work if the audio hardware on the graphics device is different for each video device.
Check the layout when it is good, and when it flips, and assign your names to the devices based on that. Then, you can only try and see if it works.
You might have to go down the rabbit hole to investigate further if this is irritating enough to you. e.g. ask on the alsa mailing list, web searches for people who have this exact problem and solved it, etc.
On Mon, 25 Jul 2022 07:55:23 -0700 stan via users users@lists.fedoraproject.org wrote:
You might have to go down the rabbit hole to investigate further if this is irritating enough to you. e.g. ask on the alsa mailing list, web searches for people who have this exact problem and solved it, etc.
A couple of relevant links:
On Mon, 2022-07-25 at 07:55 -0700, stan via users wrote:
I think this is a consequence of parallel boot. The order in which devices are discovered is non-deterministic.
Or, at all. Occasionally my system doesn't find any audio hardware.
Many of us are in this "which card?" boat, because of modern hardware being quite different from ye olde. There's the on-board sound, which may or may not have anything plugged into it (mine doesn't). A HDMI video monitor which may support sound (mine does). And we may (I do) have some USB audio hardware plugged in. While I could disable the on- board sound (assuming that a UEFI option really disables it and the OS doesn't find it again), I can't disable the HDMI audio and it is useful to be able to manually select it, some times.
Somehow it's supposed to determine which one to use. And we'd hope that once we've set a preference in our login account (e.g. using whatever pulseaudio volume control app applies, in my case I'm using "mate-volume-control") it would stick.
Ideally, these volume control apps need improving so that they clearly identify hardware precisely (not configure things to use the first found device method, when *we* know that's not a fixed answer), and write the config in such a place that it's paid attention to.
I've had a look at the link in your next message: https://alsa.opensrc.org/MultipleCards But I may as well be reading NASA specs on the space shuttle, there's a presumption of prior knowledge.
On Mon, Jul 25, 2022 at 6:19 PM Tim via users users@lists.fedoraproject.org wrote:
On Mon, 2022-07-25 at 07:55 -0700, stan via users wrote:
I think this is a consequence of parallel boot. The order in which devices are discovered is non-deterministic.
Or, at all. Occasionally my system doesn't find any audio hardware.
Many of us are in this "which card?" boat, because of modern hardware being quite different from ye olde. There's the on-board sound, which may or may not have anything plugged into it (mine doesn't). A HDMI video monitor which may support sound (mine does). And we may (I do) have some USB audio hardware plugged in. While I could disable the on- board sound (assuming that a UEFI option really disables it and the OS doesn't find it again), I can't disable the HDMI audio and it is useful to be able to manually select it, some times.
Audio devices (like disk partitions) should have UUID's so order of discovery can be ignored.
Somehow it's supposed to determine which one to use. And we'd hope that once we've set a preference in our login account (e.g. using whatever pulseaudio volume control app applies, in my case I'm using "mate-volume-control") it would stick.
Ideally, these volume control apps need improving so that they clearly identify hardware precisely (not configure things to use the first found device method, when *we* know that's not a fixed answer), and write the config in such a place that it's paid attention to.
I've had a look at the link in your next message: https://alsa.opensrc.org/MultipleCards But I may as well be reading NASA specs on the space shuttle, there's a presumption of prior knowledge.
It would be helpful to have a tutorial "How to manage multiple audio devices" using slots.
The capabilities to get around the order in which devices are discovered is there, but the user tools need a higher-level way to present and manage the priority and switch between devices. I suspect a really effective solution might require some changes at the hardware level to support UUID's that would be the same when a (USB) device is moved to a different system.
Hi George N. White III:
It would be helpful to have a tutorial "How to manage multiple audio devices" using slots.
Yes!
The capabilities to get around the order in which devices are discovered is there, but the user tools need a higher-level way to present and manage the priority and switch between devices. I suspect a really effective solution might require some changes at the hardware level to support UUID's that would be the same when a (USB) device is moved to a different system.
If I switch on my USB audio device and then read the tail of dmesg, I see this:
[508825.312474] usb 1-12: new high-speed USB device number 7 using xhci_hcd [508825.424455] usb 1-12: device descriptor read/64, error -71 [508825.637493] usb 1-12: device descriptor read/64, error -71 [508826.514480] usb 1-12: new high-speed USB device number 8 using xhci_hcd [508826.638210] usb 1-12: New USB device found, idVendor=1397, idProduct=0503, bcdDevice= 1.00 [508826.638221] usb 1-12: New USB device strings: Mfr=1, Product=3, SerialNumber=2 [508826.638228] usb 1-12: Product: UMC1820 [508826.638235] usb 1-12: Manufacturer: BEHRINGER [508826.638240] usb 1-12: SerialNumber: 04BBF4FF
If I switch it off, wait, switch it back on again, I see this:
[568753.073218] usb 1-12: USB disconnect, device number 8 [568766.062266] usb 1-12: new high-speed USB device number 9 using xhci_hcd [568766.174287] usb 1-12: device descriptor read/64, error -71 [568766.387286] usb 1-12: device descriptor read/64, error -71 [568767.264274] usb 1-12: new high-speed USB device number 10 using xhci_hcd [568767.387993] usb 1-12: New USB device found, idVendor=1397, idProduct=0503, bcdDevice= 1.00 [568767.388004] usb 1-12: New USB device strings: Mfr=1, Product=3, SerialNumber=2 [568767.388011] usb 1-12: Product: UMC1820 [568767.388017] usb 1-12: Manufacturer: BEHRINGER [568767.388023] usb 1-12: SerialNumber: 04BBF4FF
One would presume there's enough in there to associate the device with a fixed ID. Even if it fakes the serial number, it's different from the other audio hardware in a consistent manner. Some don't provide much in the way of useful identifies, but they each use different drivers:
HDMI audio through the monitor: [ 9.884206] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 9.890273] snd_hda_intel 0000:00:1f.3: irq 127 for MSI/MSI-X
On-board audio: [ 9.916659] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC892: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line [ 9.916663] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 9.916664] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [ 9.916665] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 9.916666] snd_hda_codec_realtek hdaudioC0D0: inputs: [ 9.916668] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 [ 9.916669] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 [ 9.916671] snd_hda_codec_realtek hdaudioC0D0: Line=0x1a
More about the on-board audio: [ 9.936627] input: HDA Intel PCH Front Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input7 [ 9.937820] input: HDA Intel PCH Rear Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input8 [ 9.937879] input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9 [ 9.937938] input: HDA Intel PCH Line Out as /devices/pci0000:00/0000:00:1f.3/sound/card0/input10 [ 9.937979] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input11
More about the HDMI audio: [ 9.938019] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input12 [ 9.938060] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input13 [ 9.938819] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input14 [ 9.939107] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input15 [ 9.939154] input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input16
Outboard USB audio device: [ 10.753506] usbcore: registered new interface driver snd-usb-audio
[508825.312474] usb 1-12: new high-speed USB device number 7 using xhci_hcd [508825.424455] usb 1-12: device descriptor read/64, error -71 [508825.637493] usb 1-12: device descriptor read/64, error -71 [508826.514480] usb 1-12: new high-speed USB device number 8 using xhci_hcd [508826.638210] usb 1-12: New USB device found, idVendor=1397, idProduct=0503, bcdDevice= 1.00 [508826.638221] usb 1-12: New USB device strings: Mfr=1, Product=3, SerialNumber=2 [508826.638228] usb 1-12: Product: UMC1820 [508826.638235] usb 1-12: Manufacturer: BEHRINGER [508826.638240] usb 1-12: SerialNumber: 04BBF4FF
Switching the USB audio device off and on again is often enough to get the device noticed by my system and sound go over to it. I'm fortunate that it's a device with a power switch. Though I really shouldn't have to do that.
On Tue, Jul 26, 2022 at 11:06 AM Tim via users < users@lists.fedoraproject.org> wrote:
Hi George N. White III:
It would be helpful to have a tutorial "How to manage multiple audio devices" using slots.
Yes!
The capabilities to get around the order in which devices are discovered is there, but the user tools need a higher-level way to present and manage the priority and switch between devices. I suspect a really effective solution might require some changes at the hardware level to support UUID's that would be the same when a (USB) device is moved to a different system.
If I switch on my USB audio device and then read the tail of dmesg, I see this:
[508825.312474] usb 1-12: new high-speed USB device number 7 using xhci_hcd [508825.424455] usb 1-12: device descriptor read/64, error -71 [508825.637493] usb 1-12: device descriptor read/64, error -71 [508826.514480] usb 1-12: new high-speed USB device number 8 using xhci_hcd [508826.638210] usb 1-12: New USB device found, idVendor=1397, idProduct=0503, bcdDevice= 1.00 [508826.638221] usb 1-12: New USB device strings: Mfr=1, Product=3, SerialNumber=2 [508826.638228] usb 1-12: Product: UMC1820 [508826.638235] usb 1-12: Manufacturer: BEHRINGER [508826.638240] usb 1-12: SerialNumber: 04BBF4FF
If I switch it off, wait, switch it back on again, I see this:
[568753.073218] usb 1-12: USB disconnect, device number 8 [568766.062266] usb 1-12: new high-speed USB device number 9 using xhci_hcd [568766.174287] usb 1-12: device descriptor read/64, error -71 [568766.387286] usb 1-12: device descriptor read/64, error -71 [568767.264274] usb 1-12: new high-speed USB device number 10 using xhci_hcd [568767.387993] usb 1-12: New USB device found, idVendor=1397, idProduct=0503, bcdDevice= 1.00 [568767.388004] usb 1-12: New USB device strings: Mfr=1, Product=3, SerialNumber=2 [568767.388011] usb 1-12: Product: UMC1820 [568767.388017] usb 1-12: Manufacturer: BEHRINGER [568767.388023] usb 1-12: SerialNumber: 04BBF4FF
One would presume there's enough in there to associate the device with a fixed ID. Even if it fakes the serial number, it's different from the other audio hardware in a consistent manner. Some don't provide much in the way of useful identifies, but they each use different drivers:
HDMI audio through the monitor: [ 9.884206] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 9.890273] snd_hda_intel 0000:00:1f.3: irq 127 for MSI/MSI-X
On-board audio: [ 9.916659] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC892: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line [ 9.916663] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 9.916664] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [ 9.916665] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 9.916666] snd_hda_codec_realtek hdaudioC0D0: inputs: [ 9.916668] snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 [ 9.916669] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 [ 9.916671] snd_hda_codec_realtek hdaudioC0D0: Line=0x1a
More about the on-board audio: [ 9.936627] input: HDA Intel PCH Front Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input7 [ 9.937820] input: HDA Intel PCH Rear Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input8 [ 9.937879] input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1f.3/sound/card0/input9 [ 9.937938] input: HDA Intel PCH Line Out as /devices/pci0000:00/0000:00:1f.3/sound/card0/input10 [ 9.937979] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input11
More about the HDMI audio: [ 9.938019] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input12 [ 9.938060] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input13 [ 9.938819] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input14 [ 9.939107] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input15 [ 9.939154] input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input16
Outboard USB audio device: [ 10.753506] usbcore: registered new interface driver snd-usb-audio
[508825.312474] usb 1-12: new high-speed USB device number 7 using xhci_hcd [508825.424455] usb 1-12: device descriptor read/64, error -71 [508825.637493] usb 1-12: device descriptor read/64, error -71 [508826.514480] usb 1-12: new high-speed USB device number 8 using xhci_hcd [508826.638210] usb 1-12: New USB device found, idVendor=1397, idProduct=0503, bcdDevice= 1.00 [508826.638221] usb 1-12: New USB device strings: Mfr=1, Product=3, SerialNumber=2 [508826.638228] usb 1-12: Product: UMC1820 [508826.638235] usb 1-12: Manufacturer: BEHRINGER [508826.638240] usb 1-12: SerialNumber: 04BBF4FF
Switching the USB audio device off and on again is often enough to get the device noticed by my system and sound go over to it. I'm fortunate that it's a device with a power switch. Though I really shouldn't have to do that.
My devices don't have a power switch, so I unplug the USB cable, but then I end up wanting more front-panel USB ports. I just installed Fedora on an old iMac which has much better speakers than the HDMI connected monitor so has reduced the need to connect better audio devices (by USB), but no front ports unless you count the ones on the keyboard.
On Tue, 2022-07-26 at 16:20 -0300, George N. White III wrote:
My devices don't have a power switch, so I unplug the USB cable,
And the plugs and sockets wear out, they're not a good design. :-(
but then I end up wanting more front-panel USB ports. I just installed Fedora on an old iMac which has much better speakers than the HDMI connected monitor so has reduced the need to connect better audio devices (by USB), but no front ports unless you count the ones on the keyboard.
Yes, I have an ancient Mac that has better speakers than the crappy (in every way) plastic Philips HDMI monitor I'm using. It's not that hard to design speaker cavities so they sound reasonable, but some companies just don't put the effort in. Philips has enough history that they should know better.
Computer's never have enough USB ports, or enough power to drive all the devices plugged into them. Heck, mine's got about 6 or 8 (I don't recall the count of internal headers that could be connected but aren't). Yet, if I plug in keyboard, mouse, and two very basic webcams, it goes haywire. And, yes, the main PSU is a big beefy one, well in excess of real needs.
I think it's funny that we went from rudimentary home computing which started off with some featureless box (pre IBM-compatible era) which you cabled together all sorts of peripherals like some kind of three-D model of neurons. Then came the IBM compatible idea where everything bar the keyboard and monitor was slotted into the main box, and in some cases it was a completely one-piece unit bar the mains cord. Now we've gone back to spaghetti nightmare (and no, wireless peripherals isn't an improvement, just a whole new can of worms).
-
Chris Adams -
George N. White III -
stan -
Tim