If you select that sound card in Alsamixer, can you then see sliders for microphone channels?
Set them all to max (100%) and see if that helps at all.
EDIT: Hold fire. I have just re-read your last post re USB sound card used instead of internal card. So my advice above is probably irrelevant.
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.
I wonder if @FrenchPress can offer any help. She has suggested USB sound cards in other threads (e.g. Issues with Sound on Pro 16 - #23 by FrenchPress).
Do you have a photo of your "Schiit Hel" USB sound card you can attach here?
Sure thing. I took a picture of it. Here it is
I'm going to take a look at the thread you linked. Just in case here's a link to the soundcard: Schiit Audio: Audio Products Designed and Built in California
Whilst doing websearch for "Schiit Hel Ubuntu 20.04 sound".
I have just stumbled on this: Bug #1887210 “USB DAC/AMP unselectable from Sound Settings and ...” : Bugs : alsa-driver package : Ubuntu
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.
Sorry I'm bumping this thread, but I really need some help. Thank you in advance!
I had time and was reading through the bug report regarding this and below the I'm fulla schiit line, which had me rolling (love us manufacturers) something caught my eye:
apparmor="DENIED"
This should read:
apparmor="AUDIO"
This would give access to the usb for audio. I don't know if it's a kernel issue, but supposedly you can find out and even edit apparmor profiles, according to:
https://wiki.debian.org/AppArmor/HowToUse
If you feel adventurous, as i said this is way above my head, you might try messing around and see if you can get this working 
For some lite reading... here's the bug report:
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.
There is a patched kernel for this. I'm not saying it will work for you, but it would require you to build this custom kernel and install it yourself. Maybe @Aravisian wouldn't mind taking a look at it... he has more experience with building custom kernels than i do. The requirements can be found here.
From websearch of:
"cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1",
I found this, but I do not pretend to understand it: LKML: Greg Kroah-Hartman: [PATCH] ALSA: usb-audio: add Schiit Hel device to quirk table
That's the custom kernel i was referring to....i don't know if the patch itself could be applied or he would need the entire kernel. Either way it will make his kernel custom.
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.
Sources:
The patch (thanks to zabadabadoo): [PATCH] ALSA: usb-audio: add Schiit Hel device to quirk table — Linux Kernel
Devs conversation: Re: [PATCH] ALSA: usb-audio: allow -EPIPE errors for some v2 messages - Takashi Iwai
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.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
Marked solution. 232