On Wednesday, 29 April 2020 16:24:31 BST Peter Humphrey wrote: > On Wednesday, 29 April 2020 10:15:09 BST Peter Humphrey wrote: > > I'm still puzzled at why creating an asound.conf enabled - phonon? - to > > pick the right device. Alsa is not installed here, apart from alsa-lib; > > no applications. > > Well, that was a hostage to fortune. Today, after a reboot and power cycle > for maintenance work, I'm back to having no sound. > > I suspected the devices of having been detected in the wrong order, but > /proc/ asound/cards seemed to be pointing to the right one. Besides, it > seemed unlikely that a USB device would be found and set up before the > device in the display controller.
The PCI card 0 is initialised before USB hotplugging takes place. Therefore the asound.conf content would be parsed by alsa and the appropriate audio card # (USB) would/should be set as the default device. However, the device initialisation sequencing logic can be upset. It is possible things will get messy if you have a second USB audio device, in your case a webcam. I don't know if USB devices are always hotplugged in a predictable order, but I guess plugging/unplugging USB devices could change the order in which they are being detected and consequently their numbering. Therefore your card number in asound.conf could end up referencing the other USB device. > Next was to blacklist all the intel* modules and reboot again. Just the one > card found now, the USB device. Still no sound. The fact there is no intel-snd module shows your sound problem is not related to the PCI device. I expect the snd-usb-audio module was loaded though? There are three kernel/alsa centric solutions I can think of, but may be more. The first and simpler is to name your USB device in asound.conf not by card number, but by the name it is recognised as. Run: cat /proc/asound/cards then look at the name enclosed in [square brackets] after the card number and use that. There may be other naming conventions but unless I search for it I'm not sure what to advise. Obviouisly if you have two USB devices identified as "USB" this solution won't work. Another way is manage the order in which the USB devices are ordered when the module initialises them. Create a /etc/module.d/alsa.conf file and add this: alias snd-card-0 snd-usb-audio alias snd-card-1 snd-usb-audio options snd-usb-audio index=0,1 vid=0xAAAA,0xBBBB pid=0xCCCC,0xDDDD Where vendor and product IDs can be obtained and entered in the desired order by looking at the corresponding device output of lsusb. A third way is to create some udev rule(s) in /etc/udev/rules.d/ - see here for syntax: https://alsa.opensrc.org/Udev and here for different examples: https://github.com/dh1tw/remoteAudio/wiki/Persistent-USB-Mapping-of-Audio-devices-(Linux) > Have I to go the PulseAudio route after all? You do not *have to*, but if you find the PulseAudio server and associated GUI/CLI tools are convenient for you, then you can set up USE=pulseaudio and use that to mix your sound sinks and sources devices with. As Canek has already posted in most cases it just works. However, I must confess I had a spate of pa processes racing up to 100% CPU and annoyingly respawning each time I tried to kill it. An update eventually fixed this problem and it worked fine ever since.
signature.asc
Description: This is a digitally signed message part.
