alsa-project
ALC4080 - general discussion (driver support)
UCM cannot add basic functionalities when the driver does not expose them. I already explained situation in kernel bugzilla.
Note
This issue is for the kernel driver related problems. If the driver works and something is missing in UCM configuration, please, create a new issue in this tracker. It may be difficult to distinguish the right place, but if the developers redirected you here, follow the instructions bellow.
For issues like
- jack functionality assignment is unstable (jack functionality is not fixed - e.g. changes on warm reboot from windows)
- low microphone volume (which cannot be controlled using native ALSA mixer controls)
- sound is activated only after some magic plug/unplug sequence
Further steps
Try to analyze the audio driver using direct ALSA API. See DEBUG.md. Very nice report is in #528. Please, use it as a reference what to do. Developers usually do not have exact hardware, so observations describing which ALSA PCM device, which ALSA Mixer control, which ALSA Jack control can be used for given playback/capture device are essential. If the functionality cannot be handled with current ALSA audio driver, go to paragraphs bellow.
Reverse engineering of the Windows driver. Capture USB communication and save it to a file which can be replayed by wireshark. Try to write an explanation including timing (what happened in given time slots).
Driver reports should go to kernel bugzilla. Add a comment with a link here.
You may also push hardware vendors to create USB device which fully follows the USB audio specification, so the ALSA driver will work out-of-box (without "quirks").
Documentation links
The documentation is not complete. Realtek support is generally very limited to provide full specification to their codecs / audio chips those years. They are providing details only to hardware vendors with a contract. If you know more, please, let us know.
Some details
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've just sent the Realtek 'Computer Peripheral Products' team in Taiwan ([email protected]) the following polite request for help:
Hi,
The ALC4080 audio solution appears to perhaps not fully comply to the USB Audio specification, and because of this, some features for proper operations under Linux such as controlling the microphone gain are not currently exposed.
Would Realtek be so kind as to provide the required missing information/documentation so that the Linux community can enable the missing features? I would very much like to be able to use the microphone input on my $400 ASUS motherboard I've recently purchased :-)
The issue is being discussed on the Linux kernel bug tracker here: https://bugzilla.kernel.org/show_bug.cgi?id=218913
It'd be nice if one of your engineers could drop by and provide a hint or two about directions to take to resolve this issue.
Thank you for taking the time to read this and for your consideration,
Hello.
@Apteryks I already sent mail to this mail twice - one time almost year ago and second few month ago, and the same from Realtek form website.
@perexg I just got HyperX SoloCast (it use ALC4030) and looks like it has similar issue with microphone - but in this case 100% volume just enough (but it has internal AMP for microphone).
I start thinking that ALL Realtek USB cards has the similar issue or/and another way to configure some stuff (like mixer and microphone and etc).
@perexg I recorded few videos with issues I found out and workaround for some of them - for Asus support when asked them to update firmware for ALC4080. I will leave here this videos too (sorry for my English and recommend to watch it in 1.5-2x speed).
https://youtube.com/shorts/asE5SpSmJNw?feature=share - S/PDIF does not works sometimes
https://youtu.be/TF3WUR-1D5M - explanation and workaround - just does not allow suspended state for port
https://youtu.be/52FdwgR8kXY - mic issues, does not works at all after boot and quiet when work, to able use it need send some audio to line out
https://youtu.be/epKGpUYxHkk - long initialization, I recently investigated this issue and looks like issue not related to Upower, when I just unauthorized ALC4080 before UI and manually authorized it after login - it boot quickly but still initialization of audio very slow but USB already initialized (and sometimes it show that can not get sample rates and etc in kernel logs, simple helps snd_usb_audio.vid=0x0b05 snd_usb_audio.pid=0x1a5c snd_usb_audio.quirk_flags=0x2100 but no much and sometimes still show those errors)
It looks like that when PipeWire initializing ALC4080 it block some stuff to load or act (I even disabled Upower that seems to block login screen - but the same, https://gitlab.freedesktop.org/upower/upower/-/issues/288 I am going to close it)
https://youtu.be/mOtnC0oWecc - when I send audio to Line Out I can hear it silently from Headphone Out and vise versa - sims that it incorrectly configure internal mixer (or need some additional configuration) and the same in case with 7.1 mode, I can hear sound from channels that I should not. Seems like device does not provide info about mixers or jack re-tasking properly or something like that.
@perexg Hello I just added my USB capturing .pcapng files with video link with timings when I click on something - https://bugzilla.kernel.org/show_bug.cgi?id=218913
For me it seems that driver sent nothing right after click on control panel, maybe right before start audio/capturing - I not sure.
For anyone who want to capture their codecs too but without installing Windows on host - here some instruction to speed up this investigation.
First of all recommend to download:
- Windows 10 (Windows 11 require UEFI) - https://www.microsoft.com/software-download/windows10ISO
- Virtio ISO image - https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/
- Install QEMU on host system
- Install on HOST Wireshark using your package manager
QEMU setup
- Create image -
qemu-img create -f qcow2 win10.qcow2 100G - Run QEMU
sudo qemu-system-x86_64 \
-smp 8,cores=8,threads=1,sockets=1 \
-cpu host \
-vga qxl \
-machine accel=kvm \
-m 16384 \
-nic user,model=virtio-net-pci \
-rtc base=localtime \
-usb -device usb-tablet \
-name "Windows 10" \
-device virtio-blk-pci,drive=drive0,id=virtblk0,num-queues=8 \
-drive file=win10.qcow2,if=none,id=drive0,format=qcow2,index=0 \
-boot once=c,menu=on \
-nodefaults \
-display gtk,zoom-to-fit=off \
-device qemu-xhci,id=xhci -device usb-host,bus=xhci.0,hostdevice=/dev/bus/usb/001/003 \
-drive file=Win10_22H2_Ukrainian_x64v1.iso,media=cdrom,index=0 \
-drive file=virtio-win-0.1.271.iso,media=cdrom,index=1
PS: /dev/bus/usb/001/003 - you should put here your path to ALC4080
PSS: It will automatically unbind device from drivers
PSSS: Run QEMU with root permissions - it need to properly work with USB
Installation:
- During first run it should automatically run Windows Installer
- During installation Windows Installer should ask you where get drivers - just click to load from disk and select proper driver from Virtio ISO image
- After installation recommend to open in Windows - Virtio ISO cdrom and open setup wizard to install all other drivers like QXL video driver and network driver and etc
- After download into Windows driver for your ALC4080 from MB website and install it - in device manager it should be device near all other USB devices and without any warnings that this device can not be started or initialized.
- Run on HOST -
sudo modprobe usbmon - Run on HOST Wireshark with root permissions, like
sudo wireshark- it need to able capture USB - Now you will see
usbmonX, where X it USB bus number - click on needle one - In filters write
usb.device_address == deviceNumber- replace deviceNumber by actual one - Save your dumps in format to able it open again - I not sure what better I selected default one .pcapng
PS: Do not forget about reboots of VM
PSS: When you will capture please select proper USB for capturing - for example if your parameter for QEMU looks like this hostdevice=/dev/bus/usb/001/003 it mean that you need to select usbmon1 and set filter to something like that usb.device_address == 3
PSSS: Driver not always send to USB packets right after click - I not sure, maybe it does right before audio acting or I don't know. I mean that in case when it nothing send need trigger some acting with audio or microphone depend on option your changed - like play audio or listen microphone.
Also I think you need to records video or record all timings when you did some action to able determine it in dump.
As mentioned before by @perexg - better to report about it to https://bugzilla.kernel.org/ (it already has some issues related to microphone especially like - https://bugzilla.kernel.org/show_bug.cgi?id=218913 )
I think that should be enough.
Maybe, need simultaneously report about those issues to MB Vendors or to Realtek - maybe some of them will help with documentation or firmware updates
@serhii-nakon : It would be probably better to capture USB packets directly in Linux for whole USB communication - https://github.com/liquidctl/liquidctl/blob/main/docs/developer/capturing-usb-traffic.md#capturing-usb-traffic-on-linux . Then filter only packets for the ALC4080 USB device. Perhaps, you may update installation steps in your comment (and big thanks for this).
@perexg OK, I will try it. I think it not big issue due VM already configured and only need capture on Linux side. I think I will try to capture USB while VM booting - to check does VM send some firmware or other stuff.
also 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.
4082-crosshair-hero-x670e.pcapng.gz
https://github.com/user-attachments/assets/611ccbf6-053a-49d2-8732-5baf4b7f54ff
also 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.
4082-crosshair-hero-x670e.pcapng.gz
https://github.com/user-attachments/assets/611ccbf6-053a-49d2-8732-5baf4b7f54ff
@LuanVSO When you changed some options, sometimes driver did not send anything - try change, and listen microphone or start audio (depend on option you changed) - for example maybe option like Mic Boost send something right before or simultaneously with starting using Microphone (on your video no packets to codec after you changed Mic Boost).
Also maybe better do some delays due it can be hard to determine where every packet in this dump or/and in case if driver send packets asynchronously.
@perexg I added new dumps captured outside of VM to this issue - https://bugzilla.kernel.org/show_bug.cgi?id=218913 For me it looks pretty much the same.
Also I updated instruction,
@serhii-nakon Fantastic! Thank you for sharing the captures and the instructions. 😃 I really hope someone from the kernel driver takes a look at those.
@LuanVSO Thank you for the captures! But please post those here on the kernel issue, so that the kernel developers can make use of it: https://bugzilla.kernel.org/show_bug.cgi?id=218913 Or if you don't feel like creating an account, I can share them there for you.
Here's my contribution re: #462 - playing DTS and Dolby Digital surround feeds via S/PDIF
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
I recently switched from a very old computer to a new one with a MSI X870E Tomahawk motherboard, that uses the ALC4080 codec. Shows up as Bus 001 Device 002: ID 0db0:cd0e Micro Star International USB Audio.
It works fine for stereo audio, and the front headphone jack also works fine (my mic is USB so I have not tested the amplification).
But I cannot use it for 5.1 surround. The motherboard manual instructions says I should use Line-in and front mic jacks for output, but those jacks does not seem to be remapped to outputs when I set it to HiFi 5.1 channels mode.
Is this the same issue? Would it be helpful if I also captured and posted the USB packets from a Windows VM?
@LZZZZ I am not sure, but I think the card needs to be put in some "surround mode" by the driver. So yes, it also ends up being a lack of driver support.
It looks like the kernel issue is not getting much traction, which is a shame because the ALC4080 is becoming a standard on a big chunk of new motherboards.
Hello!
To add one more data point to the report:
I have ASRock X870E Taichi motherboard which uses ALC4072 chip, and my headphones are connected to the rear jack and since my distro has updated to pipewire 1.4.1, the audio volume output has been clamped to 1-10% of the volume scale. i.e. 5% = half of the maximum volume, 10% = maximum volume, with no changes in 11-100% range.
The pipewire issue is here, amd the folks have asked to share the info in this project: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4624
@LZZZZ Hello more likely you need first of all check version of your DE, PipeWire and Alsa UCM configs, if everything pretty new more likely you need to play with Alsa UCM configs to properly match jacks
@nfp0 Hello, I tried surround 5.1 and 7.1 and everything works but except some channels interference with each other if no audio on this channel or it is but very quiet (in general the same with headphone out and rear out in stereo mode - maybe hardware issue), and exactly the same bug I got from Windows VM with connected ALC4080 directly into VM by USB and with Realteck driver installed from site of my mobo - it seems that most things works due it USB UAC 2 compatible, but ALC4080 just buggy itself, I even think that here no hardware amplifier for microphone and on Windows it works just because software amp inside Realteck driver that act to windows like it has amp...
I just bought external sound card and usb mic and everything works just perfect I even disabled ALC4080 from bios to speedup booting of my OS
Also I have recommendation to everyone that has this codec - disable auto suspend of jack ports and S/PDIF ports on PipeWire or Wireplumber configs, it will avoid issues when audio just disappear after you stopped audio for few seconds - looks like it buggy suspend mode and sometimes it just does not return from suspend mode
@serhii-nakon The channel interference sounds like some hardware issue, but I haven't tested surround on my board.
I even think that here no hardware amplifier for microphone and on Windows it works just because software amp inside Realteck driver that act to windows like it has amp...
Yes, I also thought that might be the case. I have also been curious about that, and there is one way to confirm this: Since you already have the whole setup ready on a Windows VM, could you please capture the USB packets that are sent (outgoing only) to the sound card when you enable/disable the microphone amplification? Make sure you are capturing audio at the same time in some app to make sure the change is being sent to the audio card immediately.
I believe you can use Wireshark to capture USB packets.
@nfp0 It does nothing, when i just changed amp volume from 0 to 30db it send nothing at all between USB and codec, here possible that it can change AMP configs during microphone works but it hard to record (I recorded but here too much data, due it captured microphone data that sent from codec to usb)
@serhii-nakon Yes, there will be too much data if you capture everything, but if you filter by outgoing packets only, the incoming packets should not show up. Try filtering by outgoing packets only.
I was able to get 5.1 setup working with a little coding with libusb: https://pastebin.com/3bdAwD74
Compile with g++ -std=c++23 -lusb-1.0 <filename>.cpp, run as root.
@patlefort Can you perhaps find a way to enable the Gain setting with that same method?
@serhii-nakon Any luck filtering by outgoing packets only.
@serhii-nakon Any luck filtering by outgoing packets only.
Hello @nfp0 I deleted VM nearly few months ago, I recorded everything and it possible to filter packets in already created dump I think.
I use all this time external DAC with external usb mic due I found additional slight noise while using eGPU