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