It just stays like that. Can't move the volume up nor down. I've read that some DACs do not expose their controls to Alsamixer and are only to be controlled with software like Pulseaudio. But it doesn't explain why the mic sound so quiet.
"USB Mixer" looks a strange description of a sound card.
What choice of soundcard/s do you see when you hit [F6] in Alsamixer?
Can you post a screenshot of that result.
I'm not sure what to call this device. It is amp/DAC combo. It is connected to the PC via USB cable and I use it to connect my headphones. So I guess it is a soundcard as I don't use the one on my motherboard. Anyway, here's the screenshot.
Yes, I see a lot of different sliders. I have set them to maximum and tried to record my voice after each change, but it did not have any effect on my DAC and headphones.
Yup, saw that one too. There was another post somewhere but I forgot where I saw it. They were all unresolved so that's why I didn't bother to link them.
First of all, thank you for your help! I'm really glad you came up with a possible solution. I must apologize for not responding for a long time. I lost all hope and kinda abandoned this thread.
BUT now I'm back and I will take a closer look at the AppArmor thing once I have more free time. It looks quite complicated to be honest. I've always avoided AppArmor, because it is something that my brain just refuses to process.
Alrighty here comes a quick update, I decided to do some basic troubleshooting and it seems like I don't have any problems with AppArmor (yaaay!). I used dmesg -w after unplugging and plugging my soundcard. Here's what the good ol' terminal said:
[13500.978134] usb 1-7: USB disconnect, device number 4
[13504.423921] usb 1-7: new high-speed USB device number 7 using xhci_hcd
[13504.678636] usb 1-7: New USB device found, idVendor=30be, idProduct=0101, bcdDevice= 1.02
[13504.678644] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[13504.678647] usb 1-7: Product: Schiit Hel
[13504.678649] usb 1-7: Manufacturer: Schiit Audio
[13504.830510] input: Schiit Audio Schiit Hel as /devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-7/1-7:1.3/0003:30BE:0101.000B/input/input33
[13504.884560] hid-generic 0003:30BE:0101.000B: input,hidraw3: USB HID v1.00 Device [Schiit Audio Schiit Hel] on usb-0000:01:00.0-7/input3
[13505.541362] usb 1-7: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
[13505.562359] usb 1-7: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
[13505.590363] usb 1-7: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
[13505.660385] usb 1-7: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1
Nothing about AppArmor, but it still complains about ctl values. Whatever that means. Can't seem to find anything about this mysterious thing. I will continue with troubleshooting tomorrow.
As far as I know it doesn't affect the usability of the device. I have enabled ctl_error_ignore in order to be able to select Schiit Hel in Alsamixer. Although I'm not entirely sure that it is the best thing to do. Maybe you are right and I have to modify the kernel but that sounds scary. It's a true witchcraft to me
After some digging I found out very useful information. It seems like there is a problem with Schiit Hel on a kernel level. I can't tell you what exactly is wrong as I don't understand this level of technical jargon.
Now the good news are that a fix is already developed. Bad news is that the patch will be available in kernel version 5.15 or 5.16. I could theoretically install 5.15.rc3, but it is an experimental build and I'm afraid of breaking everything. I was also looking for information on modifying this module myself in order to apply the fix, but the more I read all the guides and documentation the more I understood that I don't have a clue.
Yes, 5.11.0-37 can be patched. But you would have to lock the custom kernel in to prevent it being updated.
I would also need to patch 5.15 for you if you went that route anyway, due to the libc6 dependency issue that Canonical could very easily fix, but doesn't for reasons unknown.
I appreciate your help! I think that the best thing for me to do would be to wait for the new kernel release. In the meantime I will use different microphone connected to the motherboard's soundcard.
Thank you everyone for your valuable time and help!
I am glad to hear you have this option. Because... I did not like the idea of compiling two untested kernels for you to use.
Kernels can do some Very Strange Things if they balk. It's a Risky Move.