On Wednesday, 15 June 2022 17:29:54 BST Julien Roy wrote: > On 6/15/22 06:52, Peter Humphrey wrote: > > I do something like that by copying a good user account as a basis for the > > next iteration. The problem is just the fineness of granularity that's > > needed, now that a coarse grain hasn't helped. Hey-ho. Here we must go > > again... > What is certain is that the issue is caused by a file in your home > directory, since creating a new user fixes the problem. > > What may help you to be more specific with this would be to list what > files were modified since the last time audio worked; for example, `find > $HOME -mtime 0` will show files modified in the last 24 hours > > You might want to run this command on .config or .kde directories to see > what could have changed, although it's true that it might take a while > to pin point it... > > Another option, since you mention that you re-created your user multiple > times, is to just delete specific folders, reboot, and try audio. Maybe > start with .config as that would be the most obvious culprit. If that > doesn't work, try .kde (not sure if that folder is in ~/ or ~/.config), > then other directories. > > Also, did you check `dmesg` to see if there are any errors related to > the audio device/driver? Try `dmesg --level=err,warn` > > > Regards, > > Julien
I can't recall if among various things Peter has tried is to boot and login into Plasma, without the USB audio dongle plugged in. Then plug it in and check dmesg and syslog, as well as udevadm: udevadm monitor --subsystem-match=usb --property Also, if there is some specific audio driver module used with this dongle, try compiling it as a module and modprobe it manually. Hopefully, checking differences between the working and non-working user profiles before/after a reboot will elicit something meaningful.
signature.asc
Description: This is a digitally signed message part.
