Created attachment 306370 [details] ALC4080 BLOCK SCHEME I found simple documentation about ALC4080 and block scheme show that it has hardware boost with 4 possible cases - +0db,+10db,+20db and +30db Here this scheme https://www.igorslab.de/en/the-old-alc4080-on-the-new-intel-boards-demystified-and-the-differences-from-alc1220-insider/ Here my alsa-info log http://alsa-project.org/db/?f=b8bbd4bd74e59d83d109b768e4d3e5e1bc8b8c81 Also if you look at this block scheme you will see that after ADC we can see Volume control that has control range from -17 to +12db - and only this part controlled by Linux/ALSA. Expected way to able control boost block to specify boost value or at least boost it by default by driver. Sorry if I something missed (it my first bug report here) - if you will need some additional information please ask.
Looks like very similar bug https://bugzilla.kernel.org/show_bug.cgi?id=217786 but here reported for only one mobo - but this issue is global I think
Created attachment 307224 [details] ALC4080 datasheet
Just added ALC4080 datasheet - i believe it help with problem.
ALC4080 is USB codec, thus it exposes functionality through the USB bus. The block scheme is nice to know internals, but look to the MCU paragraph in the datasheet: 2.1.2. Micro Controller Unit - On-chip high-performance and low-power MCU - Ultra-low power consumption when MCU is at idle state - MCU controls connection to USB bus for re-enumeration without hot-plug - Internal programmable memory support for customized audio function - Watchdog control for MCU reset and interrupt - Configurable VID (Vendor ID), PID (Product ID), and serial number string This means, that the internal firmware for this MCU unit can change the behaviour of audio hardware. Usually, the firmware is vendor specific. The USB audio hardware should comply with the USB Audio specification (refer https://www.usb.org). The control units parsed by the ALSA driver can be obtained using 'cat /proc/asound/cardX/usbmixer' command (replace X with the correct ALSA card number). Those units are mapped to the standard mixer controls. My guess is that the firmware is not complaint with the USB audio specification and some functionality is controlled using specific USB handshake (data blocks). I see two ways: - reverse engineering of the Windows drivers (capture USB communication) and try to analyze it - push hardware vendors to follow fully USB Audio specification, so all functionality is exposed using this standard protocol (ideal world)
I will try to capture USB data transfers between VM and ALC4080 when I will have enough time.
(In reply to Jaroslav Kysela from comment #4) > ALC4080 is USB codec, thus it exposes functionality through the USB bus. The > block scheme is nice to know internals, but look to the MCU paragraph in the > datasheet: > > 2.1.2. Micro Controller Unit > - On-chip high-performance and low-power MCU > - Ultra-low power consumption when MCU is at idle state > - MCU controls connection to USB bus for re-enumeration without hot-plug > - Internal programmable memory support for customized audio function > - Watchdog control for MCU reset and interrupt > - Configurable VID (Vendor ID), PID (Product ID), and serial number string > > This means, that the internal firmware for this MCU unit can change the > behaviour of audio hardware. Usually, the firmware is vendor specific. > > The USB audio hardware should comply with the USB Audio specification (refer > https://www.usb.org). The control units parsed by the ALSA driver can be > obtained using 'cat /proc/asound/cardX/usbmixer' command (replace X with the > correct ALSA card number). Those units are mapped to the standard mixer > controls. > > My guess is that the firmware is not complaint with the USB audio > specification and some functionality is controlled using specific USB > handshake (data blocks). > > I see two ways: > > - reverse engineering of the Windows drivers (capture USB communication) and > try to analyze it > - push hardware vendors to follow fully USB Audio specification, so all > functionality is exposed using this standard protocol (ideal world) Hello again. I gain requested ASUS Support to help with this issue. Also I have additional questions: 1) by some reason microphone detection works, but no signal until I send some short audio signal to Line Out then I get microphone signal (but silent) 2) also ALC4080 on my system initialize to long (sometimes it even block upower then gnome login), it can take 30-60 seconds - does it possible to unblock or delay initialization or speedup it? 3) in logs sometimes I see this: [ 14.096546] usb 1-6: 1:1: cannot set freq 192000 (v2/v3): err -110 [ 24.336559] usb 1-6: parse_audio_format_rates_v2v3(): unable to retrieve number of sample rates (clock 1) [ 29.456531] usb 1-6: parse_audio_format_rates_v2v3(): unable to retrieve number of sample rates (clock 1) Also i already applied quirk_flags - it a bit help with optical output QUIRK_FLAG_CTL_MSG_DELAY | QUIRK_FLAG_DISABLE_AUTOSUSPEND snd_usb_audio.vid=0x0b05 snd_usb_audio.pid=0x1a5c snd_usb_audio.quirk_flags=0x2100 Upower issue related to ALC4080 time initialization - https://gitlab.freedesktop.org/upower/upower/-/issues/288
*(but silent) -> very quiet
I have a similar issue on an MSI X870 Tomahawk motherboard with the ALC4080 onboard sound (very low mic volume). And I have found no way to increase the mic volume on ALSA. I have confirmed that the problem also exists on Windows when no drivers are installed. But with the drivers installed, a setting to adjust Mic Gain becomes available, which allows the mic volume to reach reasonable levels. Would it be helpful if I provided a USB packet capture from Windows when Mic Gain is changed there? ALSA info dump provided here if it is in any way helpful: https://github.com/alsa-project/alsa-ucm-conf/issues/455#issuecomment-2431812596
For me it seems like all Realtek USB has some issues with USB UAC (USB Audio) compatibility and they use own way to control some parts of codecs like microphone boost control or jack re-tasking and etc. Looks like really better reverse engineer Realtek driver or get from them some information to control of non UAC compatible parts (it seems that all all their USB cards has exactly the same 4 steps boost for example - +0db, +10db, +20db, +30db)
Also related issue to this one https://github.com/alsa-project/alsa-ucm-conf/issues/541
Hello I recorded communication between Realtek driver and ALC4080 for: 1) Mic boost 2) AMP mode (like normal, powerfull, extreme) 3) While changed surround mode (like 2/4/5.1/7.1 channels) Here link to the video where I captured everything to know timings when I click something and etc - https://youtu.be/2F4CTjzNiJ8 And I will attach archive with .pcapng files from this video to all attachments in this thread. I noticed that driver set something right before or at the same time after start capturing audio or start audio (only changing AMP mode sent some packages to USB right after click). Also I noticed that here anyway exist issue when I can hear audio from Line OUT when in OS I send it to Headphones output (maybe the same in surround mode still exist but I not sure - due I connected only line out and to front panel headphones and did not noticed issue) Also sometimes in Windows it anyway long initializing codec by some reason PS: I wrote about it to make sure that it not only on Linux issue but on Windows too.
Ahh sorry, I can not attach it due limits on attachments in 5MB Here link to Google Disk with archive - https://drive.google.com/file/d/14zAKcCUnohRVcphzH21JHAU6IB1FubvA/view?usp=drive_link
Also captured USB actions using Wireshark outside of VM: Here link to archive with dumps of capturing - https://drive.google.com/file/d/1V3BaHx-uKESLpwkHNDgP8iJfLUqbHt1Y/view?usp=sharing Here link to video with all timings when I click - https://youtu.be/5tWyy3Z9Co0
i also did a capture, and was instructed to share it here: did the capture on my crosshair hero x670e, also included plugging and unplugging the headphone connection in the capture since the impedance detection seems to misbehave if i boot the vm with something already connected. https://1drv.ms/u/c/b20a0ed044edf2c7/EY-WqpXVh29AnWmj5xqVLDsB_zaU6JixxWAnz_OJk7S8Wg?e=50M9K7 https://youtu.be/JZkCqNSSvCc
Does it possible that Realtek driver does not use hardware AMP for microphone and amplify it by software?
Another capture: playing DTS and Dolby Digital surround feeds via S/PDIF on an ALC4080 (ASRock X870 Steel Legend) Packet capture video: https://youtu.be/RqjN_oxv70o Packet capture matching the actions: https://github.com/cybik/pcap-upload/blob/trunk/USB%20Pcap%20realtek.tar.xz