Hi,
I’ve got a new motherboard with Realtek ALC4080 sound. The front panel “headphone” jacks don’t work. It detects when I plug something in, but no audio comes out.
I loaded Windows just to be sure it’s not a hardware issue, and everything works there.
Everything looks OK in alsamixer. It seems to think it is playing audio, but it’s not.
Can anyone help me figure this out?
Have you tried running PAVC (Pulse Audio Volume Control)? You may need to first install it.
Thanks for the reply…
Same. It shows the bar moving as if audio is playing. But, there is no sound.
My guess is that the headphone amp is not powered… if that’s even possible. But I am thinking the ‘generic’ driver knows the headphones are plugged in and tells the sound chip itself to start sending audio… and it likely is. But then the amplifier isn’t turned on… My only reason for suspecting this is that Gigabyte talks about their ‘high end’ headphone amp, so that is a component which is maybe not standard. I don’t know though. That’s mostly just a random guess.
It’s a new z590 motherboard… And this alc4080 is a new audio chip, I think…
The ALC4080 reads to be a ‘different kettle of fish’ compared to previous hardware audio codecs. I note this article about the ALC4080. It claims the ALC4080 is a single-chip, multi-channel USB audio codec that embeds a USB 2.0 controller with a high-performance audio codec.
I find that strange.
Its quite possible you may be in ‘bug reporting’ territory, but before we totally jump to that conclusion, could you run a diagnostic script to assist in a further analysis? To do so, please open an xterm/konsole, and with PC connected to the internet, as a regular user, paste in this command:
/usr/sbin/alsa-info.sh
Let the script run to completion, selecting the UPLOAD/SHARE option. After the script run has completed, in the xterm/konsole you should read something like:
Your ALSA information is located at http://alsa-project.org/db/?f=some-number
Please inform the person helping you.
Please post that http address-URL here. We can look at it and see if it offers any insights to the issue.
Did read the article linked by @oldcpu and did read:
And concerning the capacitor-free port D: Now you know why I always tell you to connect the headset to the front panel, unless the manufacturer has provided a fat jack socket for the “special” audio output on the I/O shield! By default, port D is always connected via HD Audio and thus via the front panel. If that’s too quiet for you, just test it in the back. One output actually always works with the 2 volts and the automatic impedance detection.
@wicked1: Do you have a voltmeter? If so it is good to check if there is a voltage on the front panel “headphone” jack, that way you know it is connected correctly.
Thanks for the replies everyone.
My guess is the switch to USB is so they can make simple chips containing everything, and use them in both USB dongles and internal sound ‘cards’. Use the same chip for everything, and tack on special caps, etc, for the expensive models.
Here’s the ALSA info:
[FONT=monospace]http://alsa-project.org/db/?f=921a59fef53be68b32a68f551942e3909d4f3fe2
I do have a multimeter, but it’s not as simple as simply measuring 2v. It’s AC. And only 2v when there is a sine wave playing at full volume. I am in to audio… I actually build hifi amps as a pro-hobby. (hobby, but I sell them sometimes). SO… I am set up to do such a test… I’d use a scope, as that would be easier. But OTOH, I am 100% sure gigabyte didn’t screw up and put the headphone amp on the wrong output… I am quite sure the front port I am trying to use has the amp… And I’m sure it is actually working and not defective because it works in Win.
I did find a program for switching ports around for the sound card… HDAJACKRETASK. But I need to read more before I try it.
[/FONT]
Well unfortunately, the hdajackretask program doesn’t see this sound chip… It looks like it might have helped, too…
Thanks. I confess, I have not seen a alsa-info like that before, but then I am not used to the code in your device.
I noted 2 sound devices recognized by alsa:
!!Soundcards recognised by ALSA
!!-----------------------------
0 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0x51510000 irq 151
1 [Audio ]: USB-Audio - USB Audio
Generic USB Audio at usb-0000:00:14.0-11, high speed
However I only noted one codec identified, which is the HDMIcode. I thought maybe one would also see a USB codec (?) < unsure > and I did not see one.
!!HDA-Intel Codec information
!!---------------------------
--startcollapse--
Codec: Intel Rocketlake HDMI
There is a USB Descriptor section:
!!USB Descriptors
!!---------------
--startcollapse--
Bus 001 Device 005: ID 0414:a010 Giga-Byte Technology Co., Ltd USB Audio
with a massive amount of information - pretty much most of which means nothing to me.
I also note mixer information for the USB:
!!USB Mixer information
!!---------------------
--startcollapse--
USB Mixer: usb_id=0x0414a010, ctrlif=0, ctlerr=0
Card: Generic USB Audio at usb-0000:00:14.0-11, high speed
Again with lots of information - most of which also means nothing to me.
Perhaps more relevant is the aplay (below) where the USB audio is identified as card-1, with subdevices 0, 1, 2, and 3. Note that by default, openSUSE GNU/Linux will send audio to card-0 and NOT to card-1, hence that’s why users will often use ‘pavucontrol’ to redirect sound from the applications to card-1 if that is the audio device in use that drives one’s speakers.
!!Aplay/Arecord output
!!--------------------
APLAY
**** List of PLAYBACK Hardware Devices ****
... ( deleted lots of HDMI devices on card-0) ...
card 1: Audio [USB Audio], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Audio [USB Audio], device 1: USB Audio [USB Audio #1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Audio [USB Audio], device 2: USB Audio [USB Audio #2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Audio [USB Audio], device 3: USB Audio [USB Audio #3]
Subdevices: 1/1
Subdevice #0: subdevice #0
Then if we look at the amixer we can see again, for hw:1,0 that sound is muted, all playback at 0%:
!!Amixer output
!!-------------
!!-------Mixer controls for card PCH
... (deleted lots of IEC958 for HDMI ) ....
!!-------Mixer controls for card Audio
Card hw:1 'Audio'/'Generic USB Audio at usb-0000:00:14.0-11, high speed'
Mixer name : 'USB Mixer'
Simple mixer control 'PCM',0
Capabilities: pvolume pswitch pswitch-joined
Playback channels: Front Left - Front Right - Rear Left - Rear Right - Front Center - Woofer - Side Left - Side Right
Limits: Playback 0 - 87
Mono:
Front Left: Playback 0 [0%] -65.25dB] [on]
Front Right: Playback 0 [0%] -65.25dB] [on]
Rear Left: Playback 0 [0%] -65.25dB] [on]
Rear Right: Playback 0 [0%] -65.25dB] [on]
Front Center: Playback 0 [0%] -65.25dB] [on]
Woofer: Playback 0 [0%] -65.25dB] [on]
Side Left: Playback 0 [0%] -65.25dB] [on]
Side Right: Playback 0 [0%] -65.25dB] [on]
Simple mixer control 'PCM',1
Capabilities: pvolume pswitch pswitch-joined
Playback channels: Front Left - Front Right
Limits: Playback 0 - 87
Mono:
Front Left: Playback 60 [69%] -20.25dB] [on]
Front Right: Playback 60 [69%] -20.25dB] [on]
If I read that correctly, the hw:1,0 playback is set to 0% - which means NO audio playback if hw:1,0 is your audio output jack (and I have no idea if that is your audio output jack).
The hw:1,1 is at 69%, and the hw:1,2 appears to be a line-in or a mic. I could not see a " ‘PCM’,3 " which I assume (mistakenly ?? ) would be the hw:1,3. As noted this is all new to me for your hardware.
I can’t tell if anything wrong in the dmesg entry … where I note:
!!ALSA/HDA dmesg
!!--------------
...
6.616235] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000
7.501744] usb 1-11: New USB device found, idVendor=0414, idProduct=a010, bcdDevice= 0.07
7.501748] usb 1-11: Manufacturer: Generic
7.624250] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000
7.648246] usb 1-12: new high-speed USB device number 7 using xhci_hcd
--
8.108218] mc: Linux media interface: v0.10
8.636256] snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it...
...
11.794807] usbcore: registered new interface driver snd-usb-audio
11.798189] usbcore: registered new interface driver usbhid
...
389.622363] <0000000086eea7c6>] i801_isr [i2c_i801]
389.622376] <000000004598d6e2>] azx_interrupt [snd_hda_codec]
389.622408] Disabling IRQ #16
As noted , I don’t understand much of that. I do note “manufacturer generic”, and I note there was 'No response from codec" with an MSI disabling after that. I have no clue if IRQ#16 disabled is relevant (as I don’t know what IRQ#16 is used for) so it may not be relevant to your motherboard sound - but I don’t know.
SUGGESTIONS:
My suggestions are to run alsamixer in a konsole/xterm, switch to the USB device, and see if you can enable audio on hw:1,0 with the mixer (as you have it muted). Then run the audo test.
I recommend to test it with some bash shell aplay commands, such as the following (where this trys to play the test.wav audio file on device hw:1,0).
aplay -D plughw:1,0 /usr/share/sounds/alsa/test.wav
To send to a hw:1,1 (for example) the command would be:
aplay -D plughw:1,1 /usr/share/sounds/alsa/test.wav
If that fails, one could try to force the audio codec to generic - which is 100% speculation on my part and quite possible not relevant.
To do that (as a speculative effort, to be removed if it does not work), add this line to the file /etc/modprobe.d/50-sound.conf (create that file if need be):
options snd-hda-intel model=generic
reboot and test per the above. Note that yast sound application will over write that edit, so don’t use that edit in combination with yast sound app.
Thanks for the analysis.
About the muting… It auto mutes the ports which are unplugged. So at that time, I had the front port plugged in, which is the one showing 69%.
In Yast, Audio, it only shows the Intel HDMI audio… I’m not sure if I should install the generic usb codec there… Sound does work out the rear line-out port when I plug it in.
So basically, I have done your test number 1… Simply plugging something in to the rear port gets 1,0 working.
Plugging something in to the front port gets 1,1 working… as far as everything at this level is concerned. It shows output in the alsa report. The VU meters in all the audio apps are moving. But no audio is output
I’m still wondering if it is something Gigabyte has done w/ their own amp… In the article about the alc4080 previously mentioned, it talks about the chips in-built amps… But Gigabyte specifically talks about another headphone amp chip they use. If my first guess about that somehow being switched off is wrong, it’s also possible they use a non standard output for the front port, which is routed through their amp… I am again just making random guesses, though. If my 2nd guess is correct, that hdajackretask program would possibly fix it… But it only sees the Intel HDMI codec.
If I understand correctly, you wish to get the front port working, but instead you ran the script (to look at the configuration) where instead you had the rear port setup and not the front setup ?? Maybe I misunderstand.
My experience with YaST audio (unless its changed over the years) is mostly it will save an /etc/modprobe.d/50-sound.conf file, and then restart alsa and pulse audio (I am not so sure about Tumbleweed). So if one dislikes what YaST audio does, one can simply move the file /etc/modprobe.d/50-sound.conf file to say /home/user as a backup (don’t keep backups in /etc/modprobe.d) and then the YaST config is removed. Of course one needs to reload alsa/pulse to have the effect of removing the 50-sound.conf file applied - where the most simple way is to reboot.
I find the alsa-info script provides far more useful information than YaST, albeit the script doesn’t configure anything - it only provides useful information.
By ‘working’ I assume you mean you have sound from both rear port (hw:1,0) and sound from the front port (hw:1,1) if only one at a time is plugged in ? Or do you mean ‘detected’ but no sound for hw:1,1 (I confess if no sound I would not say ‘working’ ) ?
If sound from both ports, then what again is the issue? Is it you can’t have devices plugged into both ports at the same time?
I re-read your post - I think I understand now you ran the script with nothing plugged into the rear port, and instead had something plugged in to the front port. Hence hw:1,0 (rear port) showed muted, and hw:1,1 (front port) was at 69%.
What I don’t understand yet, is did you get sound out of hw:1,1 with the aplay command I provided?
I also don’t understand if you tried the 50-sound.conf file suggestion? (ie the " options snd-hda-intel model=generic " edit )
Possibly - but if it was me trying to test such, I would simply write a bug report on the hardware on the openSUSE bugzilla (for Tumbleweed and the kernel ) , where the openSUSE packager for sound (who is also an alsa sound driver developer) would hold my hand in debugging.
Correct, ran the script with the front headphone jack plugged in. So, rear was muted. Front was at 69% volume. But no, no sound ever comes out the headphone jacks. I meant that as far as any of the software and diagnostics I have run, they all show it as working. But no sound has ever come out of the front headphone jacks.
The rear jacks do work as they should.
Thanks for trying to help.
I’ll file a bug report after I try a few more things. I have not tried the 50-sound.conf edit yet, but I will.
Im also getting trouble with this. And i tried the other ides from here. Have anyone solve it alredy? [FONT=Calibri]พนันบาคาร่า](https://www.chokdeebacarrat.com/บาคาร่า/)[/FONT]
One further test occurred to me … and I think it highly unlikely to point to the problem cause (nor solve your issue), but it would not hurt to run this test to remove pulse audio as a possible issue.
Could you plug in to your front jack again (the hw:1,1 which was not working for giving sound) and in a konsole/xterm send this command as a regular user:
pasuspender -- aplay -D plughw:1,1 /usr/share/sounds/alsa/test.wav
The logic is simple, … the aplay is being run with pulse audio suspended. Now I do not think that pulse audio has anything to do with the sound issue, but I have been wrong before. So this would be away to gain confidence this has nothing to do with pulse (confirming my viewpoint).
My guess is sound still does not work - but if for some reason sound does work (with ‘pasuspender’) but does not work without that suspension of pulse audio, then pulse audio is part of the problem.
That works! But the pulse audio volume control software doesn’t help. It shows the headphone jack as being active, and the meter shows sound playing. But it must be telling it to use the wrong output somewhere.
Also, about some of your previous suggestions… My system does not have a 50-sound.conf file!
Thanks again for your help w/ this.
Ouch !! I did NOT expect that to work.
This suggests to me that sound works with alsa, but that it does not work with pulse audio, either because of the some automatic misconfiguation with pulse, or because of the alsa interface to pulse audio with your hardware has some issue.
This is beyond my paygrade / knowledge to help. < sigh > Maybe its time to raise a bug report …
You could just create that file with a text editor, and put that line I suggested in the file as the only line. However given sound works with alsa, I can’t see that line helping as you just proved sound works with alsa.
For some reason it appears alsa driver is not able to get the sound to pulse, or pulse is not able to receive the sound from alsa.
I wish I could help more here … but I’m out of my depth.
As a painful interim, while getting this fixed via bug report, or someone else chiming in as to what to do next, you could try to run your multimedia apps from konsole/xterm, with the " pasuspender – " in front of the application command.
Further to this, while I note its beyond my knowledge, while getting around to writing a bug report, maybe some others might chime in.
The distro archlinux has a good wiki and many of their suggestions for troubleshooting can be applied to openSUSE, even thou the distros are very different. For example ArchLinux : Pulse Audio Troubleshooting.
They have a section there, which I re copy:[INDENT=2]
Muted application
If a specific application is muted or low while all else seems to be in order, it may be due to individual sink-input settings. With the offending application playing audio, run:
$ pacmd list-sink-inputs
Find and make note of the index of the corresponding sink input. The properties: application.name and application.process.binary, among others, should help here. Ensure sane settings are present, specifically those of muted and volume. If the sink is muted, it can be unmuted by:
$ pacmd set-sink-input-mute <index> false
If the volume needs adjusting, it can be set to 100% by:
$ pacmd set-sink-input-volume <index> 0x10000
Note: If pacmd reports “0 sink input(s)”, double-check that the application is playing audio. If it is still absent, verify that other applications show up as sink inputs.
[/INDENT]
i don’t know if that will be helpful - but I guess it doesn’t hurt to try. I note that the application “pacmd” is used to “Reconfigure a PulseAudio sound server during runtime” but I have no experience using this. I had to type “pacmd -h” to learn that.
Further, if you think ‘pacmd’ worth exploring (as opposed to simply writing a bug report and waiting to see if the bug addressed), one can find examples of using ‘pacmd’ here on another archlinux wiki: Pulse Audio examples
For example, to list input sources:
pacmd list-sources | grep -e 'index:' -e device.string -e 'name:'
where in the output that command gives, the * in front of the index indicates the current default input.
.
I have never had the need to explore pacmd use with my PCs nor laptops, so I am unfamiliar with such. I also don’t know if it even relevant to helping sort the issue on your computer - which is why if it were me, in the absence of knowledgeable guidance, I would go the bug reporting route.
I have to admit, I must not have run the aplay command previously, as that also works… Without suspending pulseaudio.
Also noticed w/ the alsamixer program, it has listed:
PCM Front
PCM Rear
PCM Center
PCM Woofer
PCM Side
PCM 1
When playing the aplay command, so audio is coming out the front headphone ports, muting the first five pcm ports doesn’t change anything. But, muting “PCM 1” does mute the playback.
I think it’s safe to say “PCM Front” does not actually connect to the front audio ports. The HDAJACKRETASK program would likely be able to reassign the ports… But like I said, unfortunately, it does not see the USB sound card.
I have seen ways to force the output to always use a specific output. But I’d like the auto-switching between ports to still work. Next I need to look in to the port detection/switching routine and see if there is configuration for it. I am guessing when something is plugged in to the front port, it is activating the “PCM Front” output, which isn’t correct in this case… and maybe I can somehow specify plug 1,1.
-edit, actually just noticed “PCM Front” controls the volume for the rear speaker port, in the alsamixer program. And in KDE, I currently have something plugged in to the front and rear ports. So in KDE, I can control the volume for both outputs. Both “Headphone” and “Speaker” volume controls adjust the level of the rear speaker port.
Hi @wicked1
Did you manage to sort this out?
I also have a ALC4080 motherboard (Asus WRX80) and I’m having the exact same issue.