# No sound on GA-Z77X-UD5H motherboard (Realtek ALC898 codec)

## gemarcano

I've been too busy lately getting my new system up and going to notice that sounds wasn't working on it in a timely fashion. Today I tried to do some video editing, and I noticed that there was no sound coming from my speakers. I ran into a similar problem in the forums, but I'm getting no sound whatsoever. There is one exception, as mentioned in post #11 in this bug report: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/996245. I can confirm changing the jack to the subwoofer output in the back allows for there to be some output. I have an issue with this, since I dual-boot with Windows 7 (which has no problems with the audio), so I do not want to have to switch the audio connector every time I want to switch systems (I love Gentoo, but sadly lots of games only run well on Windows...). Since there is some audio with one of the jacks, I assume ALSA is working. Does anyone have any ideas as to what can be done to troubleshoot this? Based on what I've read, this seems to be related to the codecs or modules as implemented in the kernel... I'm more than willing to try things out, I just don't know what to try.

As a side note, I did notice the following from dmesg:

```
...

hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

...
```

----------

## audiodef

What's the output of lspci, lspci -n and lsusb?

----------

## gemarcano

lspci:

```
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)

00:01.0 PCI bridge: Intel Corporation 3rd Gen Core processor PCI Express Root Port (rev 09)

00:14.0 USB controller: Intel Corporation 7 Series Chipset Family USB xHCI Host Controller (rev 04)

00:16.0 Communication controller: Intel Corporation 7 Series Chipset Family MEI Controller #1 (rev 04)

00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)

00:1a.0 USB controller: Intel Corporation 7 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)

00:1b.0 Audio device: Intel Corporation 7 Series Chipset Family High Definition Audio Controller (rev 04)

00:1c.0 PCI bridge: Intel Corporation 7 Series Chipset Family PCI Express Root Port 1 (rev c4)

00:1c.1 PCI bridge: Intel Corporation 7 Series Chipset Family PCI Express Root Port 2 (rev c4)

00:1c.5 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c4)

00:1c.6 PCI bridge: Intel Corporation 7 Series Chipset Family PCI Express Root Port 7 (rev c4)

00:1c.7 PCI bridge: Intel Corporation 7 Series Chipset Family PCI Express Root Port 8 (rev c4)

00:1d.0 USB controller: Intel Corporation 7 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)

00:1f.0 ISA bridge: Intel Corporation Z77 Express Chipset LPC Controller (rev 04)

00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA AHCI Controller (rev 04)

00:1f.3 SMBus: Intel Corporation 7 Series Chipset Family SMBus Controller (rev 04)

01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 560] (rev a1)

01:00.1 Audio device: NVIDIA Corporation GF110 High Definition Audio Controller (rev a1)

03:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (rev 11)

04:00.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 30)

05:01.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)

06:00.0 Ethernet controller: Atheros Communications Inc. AR8151 v2.0 Gigabit Ethernet (rev c0)

07:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172 SATA 6Gb/s Controller (rev 11)
```

lspci -n

```
00:00.0 0600: 8086:0150 (rev 09)

00:01.0 0604: 8086:0151 (rev 09)

00:14.0 0c03: 8086:1e31 (rev 04)

00:16.0 0780: 8086:1e3a (rev 04)

00:19.0 0200: 8086:1503 (rev 04)

00:1a.0 0c03: 8086:1e2d (rev 04)

00:1b.0 0403: 8086:1e20 (rev 04)

00:1c.0 0604: 8086:1e10 (rev c4)

00:1c.1 0604: 8086:1e12 (rev c4)

00:1c.5 0604: 8086:244e (rev c4)

00:1c.6 0604: 8086:1e1c (rev c4)

00:1c.7 0604: 8086:1e1e (rev c4)

00:1d.0 0c03: 8086:1e26 (rev 04)

00:1f.0 0601: 8086:1e44 (rev 04)

00:1f.2 0106: 8086:1e02 (rev 04)

00:1f.3 0c05: 8086:1e22 (rev 04)

01:00.0 0300: 10de:1201 (rev a1)

01:00.1 0403: 10de:0e0c (rev a1)

03:00.0 0106: 1b4b:9172 (rev 11)

04:00.0 0604: 8086:244e (rev 30)

05:01.0 0c00: 1106:3044 (rev c0)

06:00.0 0200: 1969:1083 (rev c0)

07:00.0 0106: 1b4b:9172 (rev 11)
```

lsusb:

```
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Bus 004 Device 006: ID 2109:0810  

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 001 Device 003: ID 046d:c31c Logitech, Inc. Keyboard K120 for Business

Bus 001 Device 004: ID 046d:c05a Logitech, Inc. Optical Mouse M90

Bus 001 Device 005: ID 2109:0810  

Bus 001 Device 006: ID 2109:0810
```

I also just noticed that there is a gentoo-sources-3.4.4 available for install (I'm using ~amd64 arch), so I'll try to upgrade the kernel and report if that did anything.

----------

## gemarcano

Alright, I upgraded my kernel to 3.4.4, gentoo-sources. I still experience the problem. Now, I did a little more testing, and I found the following (Here is the back panel):

If I plugged the speakers into the orange, black, or gray jacks (Subwoofer, rear speaker, side speaker respectively), I get sound, but if I plug in the speaker into the green slot (line-out jack), I get nothing. Out of curiosity I plugged in the speakers to the line in and mic in jacks, but of course, as expected, I got nothing out of them.

----------

## audiodef

Let's start with the Intel sound chip. The one you have is well-supported by snd_hda_intel in the kernel. Do you have this either compiled in or loaded as a module?

----------

## gemarcano

BTW, thanks for your help.

```
CONFIG_SND_HDA_INTEL=m
```

I assume this means it is built as a module. Because I get some audio from the back panel (just not in the right ports), I think the module is doing something right, just not routing the audio to the correct ports. I haven't completely tested which audio ports get sound in Windows, but definitely the one I'm using for Linux right now (the black one in the middle upper section of the audio ports) does not output sound in Windows (maybe it's because of some surround sound setting not enabled in Windows, since this port has to do with surround sound as I understand it).

----------

## audiodef

The green one is usually labelled stereo out. The image you linked doesn't have enough resolution to show the jack labels. What are the black and green ones labelled?

----------

## gemarcano

Sorry, I know the link doesn't have the labels (since that's the raw back panel without the cover with the labels). According to the motherboard manual, these are the jack descriptions with their corresponding colors:

Gray- Side Speaker in a 7.1 channel audio configuration

Black- Rear Speaker in a "4/5.1/7.1" channel audio configuration

Orange- Center/Subwoofer Speaker

Red- Mic in

Green- Line Out (for standard 2 channel speaker)

Blue- Line in

In Linux if I use the green (Line Out) jack, I get nothing, but I can confirm sound coming out of the black (Rear Speakers), orange (Subwoofer), and grey (Side Speaker) jacks, but not in Windows, which expects the normal speakers to be plugged in into the green (Line Out) jack (EDIT: or so it seems like).

----------

## audiodef

That's really odd. I'm going to make a suggestion that may or may not fix it, but it will at least help ensure that your system is set up correctly and that all the necessary drivers are working. 

Go to the "seeds mirror" link in my config and get your system set up with a kernel seed. Pay particular attention to the driver section where you need the output of lspci -n. If you're new to this, there's a bit of reading involved, but it's easy to follow and understand (I help the project owner keep it legible). 

Once you boot up with your kernel-seed kernel, let me know if that changes anything for this sound card.

----------

## gemarcano

Sorry for the delay, but I haven't had the time to use the kernel seed yet. I'm familiar with customizing the kernel by hand (that... takes forever), although I'm not as thoroughly familiar with my new hardware as I would like, plus I don't know what half of the non-hardware related options in the kernel do. That having been said, I took a look at how to use the seeds, and it seems simple enough. I wish I would have found that out a while ago! It would have saved me a few days by now of manual configuration! Aw well. I should be able to compile the kernel tomorrow (or today   :Shocked: ).

----------

## gemarcano

I give up trying to get the kernel from the seed to work. I've quintuple checked the drivers needed for my system, and I still fail to get it to load properly. Should I post in the forums for the kernel seed to try to get it to boot? The problem seems to be that the kernel is panicking before graphics are set up (the boot screen flashes out, like in a normal boot with my regular kernel), and before USB drivers are loaders (I can't Ctrl-Alt-Del reboot the computer, and my optical mouse shows no signs of life). Heck, I even tried to copy some of the settings in my normal .config file over (as in, having two xconfig windows open and making things similar), to no avail (well, it did improve a little, since at first I forgot to load the nouveau drivers I needed for my Nvidia card). I'm stubborn, so once I rest a little I'll try to tackle the kernel seed once again, but man, it is annoying... This is probably because my system runs UEFI firmware, which makes booting a pain in general. I did enable all EFI required options in the kernel (at least the ones my normal one has), so that's not the problem...

----------

## gemarcano

I'm stubborn   :Very Happy: 

So, I finally figured out why the kernel could not boot. There appears to be a bug with SLUB (or at the very least, a problem with SLUB with my combination of hardware and kernel settings). That took about 6 hours to sort out...

In the end, while I was comparing the .config files, I took the liberty to trim a lot of the fat from my original one, which now resembles the kernel seeds, plus a few additions of my own. Anyhow, FINALLY getting back to the topic, I did notice a few interesting lines in the kernel configuration about Intel HD Audio. Here is how it looks for mine right now:

```
 --- Intel HD Audio                                                    

(2048) Pre-allocated buffer size for HD-audio driver                  

[*]   Build hwdep interface for HD-audio driver                       

[*]     Allow dynamic codec reconfiguration (EXPERIMENTAL)            

[*]   Support digital beep via input layer                            

(2)     Digital beep registration mode (0=off, 1=on, 2=mute sw on/off)

[*]   Support jack plugging notification via input layer              

[ ]   Support initialization patch loading for HD-audio               

[*]   Build Realtek HD-audio codec support                            

[*]     Build static quirks for Realtek codecs                        

[*]   Build Analog Device HD-audio codec support                      

[*]   Build IDT/Sigmatel HD-audio codec support                       

[*]   Build VIA HD-audio codec support                                

[*]   Build HDMI/DisplayPort HD-audio codec support                   

[*]   Build Cirrus Logic codec support                                

[*]   Build Conexant HD-audio codec support                           

[*]   Build Creative CA0110-IBG codec support                         

[*]   Build Creative CA0132 codec support                             

[*]   Build C-Media HD-audio codec support                            

[*]   Build Silicon Labs 3054 HD-modem codec support                  

[*]   Enable generic HD-audio codec parser                            

[*]   Aggressive power-saving on HD-audio                             

(0)     Default time-out for HD-audio power-save mode
```

Is there anything glaringly wrong right now?

Since I now know why the kernel seed was failing, I'll try once again using one from scratch, just changing the bare minimum, and I'll report if I see any changes.

----------

## gemarcano

Alright, I can finally give the result of running the kernel made straight from the seed with minimal drivers installed. Also, just for comparison, here is that kernel configuration's Intel HD Audio page:

```
--- Intel HD Audio   

(64)  Pre-allocated buffer size for HD-audio driver     

[ ]   Build hwdep interface for HD-audio driver  

[ ]   Support digital beep via input layer

[ ]   Support jack plugging notification via input layer

[ ]   Support initialization patch loading for HD-audio 

[*]   Build Realtek HD-audio codec support

[*]     Build static quirks for Realtek codecs   

[*]   Build Analog Device HD-audio codec support 

[*]   Build IDT/Sigmatel HD-audio codec support  

[*]   Build VIA HD-audio codec support    

[*]   Build HDMI/DisplayPort HD-audio codec support     

[*]   Build Cirrus Logic codec support    

[*]   Build Conexant HD-audio codec support      

[*]   Build Creative CA0110-IBG codec support    

[*]   Build Creative CA0132 codec support 

[*]   Build C-Media HD-audio codec support

[*]   Build Silicon Labs 3054 HD-modem codec support    

[*]   Enable generic HD-audio codec parser
```

And... the same symptoms are present. There is no sound coming out form Stereo Out/Line Out, only from the same three ports as before (colors, black, grey, and orange).

----------

## audiodef

The first Intel HD audio config was overkill, the second one is about right. 

So... you can confirm that in Windows, the stereo out (green) works, right? This is definite? Because if so, we know the card is not broken. If it doesn't work in Windows either, the card itself is the problem.

----------

## gemarcano

The Line Out green jack works fine in Windows. If I were to guess, I think the audio processing works fine in Linux as well, since I can get good-quality sound from the wrong jacks. That's the problem, though, that in Linux sound is being output from the wrong jacks... Wait. I just thought of something. I don't know if this is the case, but if Surround Sound is enabled (how would I check that?), would Line Out be disabled and give way to the other three jacks that do work (since they all have to do with surround sound)? I'll try to see if I can find anything about this.

----------

## VoidMage

Perhaps you're asking the wrong question.

Did you try other than 'default' device from 'aplay -L' list ?

----------

## gemarcano

Thanks for the tip. I hadn't thought about checking which device was being used   :Embarassed: .

That having been said, I don't seem to be making much headway. I used speaker-test to help me test where there is sound.

aplay -L

```
null

    Discard all samples (playback) or generate zero samples (capture)

default:CARD=PCH

    HDA Intel PCH, ALC898 Analog

    Default Audio Device

sysdefault:CARD=PCH

    HDA Intel PCH, ALC898 Analog

    Default Audio Device

front:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    Front speakers

surround40:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    4.0 Surround output to Front and Rear speakers

surround41:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    4.1 Surround output to Front, Rear and Subwoofer speakers

surround50:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    5.0 Surround output to Front, Center and Rear speakers

surround51:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    5.1 Surround output to Front, Center, Rear and Subwoofer speakers

surround71:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers

iec958:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Digital

    IEC958 (S/PDIF) Digital Audio Output

hdmi:CARD=NVidia,DEV=0

    HDA NVidia, HDMI 0

    HDMI Audio Output

hdmi:CARD=NVidia,DEV=1

    HDA NVidia, HDMI 0

    HDMI Audio Output

hdmi:CARD=NVidia,DEV=2

    HDA NVidia, HDMI 0

    HDMI Audio Output

hdmi:CARD=NVidia,DEV=3

    HDA NVidia, HDMI 0

    HDMI Audio Output
```

With speaker-test, I tried all of the devices except the Nvidia ones (those are HDMI, and I don't have or am not using that). I was unable to procure sound from the Line Out jack. As for the other sound-producing jacks, these do produce sound. Different surround sound configurations made the speaker be output on different channels, but using the default and front devices, all of the Center/Subwoofer Speaker, Rear Speaker, and Side Speaker jacks output sound on the channels for the front left and right speakers. Again, there was no output from Line Out.

Just in case, here are the various speaker-test commands I ran (the output is not that significant I think since it doesn't convey the actual sound or lack thereof):

For these ones,  Center/Subwoofer Speaker, Rear Speaker, and Side Speaker all gave output on front right and left speakers.

```
speaker-test -Ddefault:PCH -c2

speaker-test -Dsysdefault:PCH -c2

speaker-test -Dfront:PCH -c2
```

With surround40, Rear Speaker outputs sound in the rear right and left speakers, but Center/Subwoofer Speaker and Side Speaker output on the front right and left speakers.

With surround41, Rear Speaker outputs sound in the rear right and left speakers, Center/Subwoofer Speaker outputs only one the Center (sound comes out from my physical right speaker), and Side Speaker outputs on the front left and right speakers.

With surround50, Rear Speaker outputs sound in the rear right and left speakers, Center/Subwoofer Speaker outputs only one the Center (sound comes out from my physical right speaker), and Side Speaker outputs on the front left and right speakers.

```
speaker-test -Dsurround40:PCH -c4

speaker-test -Dsurround41:PCH -c5

speaker-test -Dsurround50:PCH -c5
```

I'm going to stop there, since I think the information is beginning to get redundant. The output seems to be governed more by the number of channels than anything else. I did try the surroundXX devices with 2 channels, and all outputted to the front left and right speakers on the  Center/Subwoofer Speaker, Rear Speaker, and Side Speaker jacks, but there was absolutely nothing coming out from Line Out for any device.

Just as additional information, as a desktop environment I am running KDE 4.8.4. I just recently switched to it from Xfce on my old computer, so I'm not very familiar with changing settings on it, yet.

With my testing, did I miss something? Any more suggestions?

----------

## gemarcano

Alright, shameless bump. It has been quite some time, and this is still a problem.

I am now running Gentoo with kernel 3.6-rc4 (I'm not using gentoo-sources because they're on the 3.5 kernels, and those kernels have a bug with nouveau rendering me unable to boot graphically). The bug is still present. I can still confirm sound works perfectly fine in Windows 7. The Ubuntu bug report I mentioned on the opening post has not really been resolved, but some people have made mention of "hda-jack-retask" as a possible workaround. I know next to nothing about retasking audio jacks... perhaps someone can chime in? I'll keep doing some research on the subject.

----------

## vexatious

I have a very similar issue going on with my mom's laptop (HP g6-1b60us) using Slackware 14.0 x64.  My sound card is also an IDT and I get alsa complaining it can't find any device.  Modules aren't loading but I managed to get some sound with audacious by manually setting the playback device to card 1 which is my analog output (card 0 is default but it's HDMI output) which is totally strange. alsaconf can't detect any device and complains about module snd not being found.

Alsamixer does load but I had to make an ~/.asoundrc to change default card to card 1 (was using card 0 hdmi as default).  All applications still report default pcm device not found (even audacious though you can manually change the playback device and get sound); no sound in internet browser (flash videos for example).  alsaequal doesn't even work with card 1 specified as default while using audacios...  

This is a very strange problem since I can get some sound but modules aren't loaded for the sound card (lsmod shows no sound modules, not even snd); also, /var/syslog reports the hardware detected as snd_hda_intel and I have the modules available.  modprobe -v snd_hda-intel doesn't say or change anything to make matters more confusing.  I'm going to try compiling the modules into the kernel and hopefully that'll improve things.

----------

## gemarcano

It has been quite some time since I've tried to figure something out in regards to this issue. Last week I started to see if I can do something about this again, since this is the only issue keeping me from booting to Gentoo on a regular basis (it's a minor issue, but I like my sound and I don't want to be using headphones all of the time).

vexatious, I don't think you and I have the same issue... My system identifies my audio cards correctly, and I can even get audio out from the green front jack, not the back. This is an issue present on the Gigabyte Z77X-UD5H motherboards. I am not aware this specific problem exists anywhere else.

As for an update, I've run into an intersting websites in the last six months, here, which used to have a solution to the problem, before Gigabyte took it down. Supposedly messing around with some resistors on the motherboard would fix the problem. The thing is, the issue is workaround-able since Windows audio works fine. My best guess would be that the UEFI doesn't report correctly where the codec pins are, probably due to some hardware problem. I think this is a hardware issue because revision 1.1 of this board has come out (with supposedly no changes to the sound chip itself), and it doesn't have an audio problem like this one...

I found some alsa troubleshooting tools, like hda-analyzer and Ubuntu's hda-jack-retask. hda-analyzer was useful in helping to see how the codec worked, but I still couldn't figure out how to make sense of the 0x14 pin (green line out). It didn't matter what I tried to do, I couldn't get it to make any sound. I played around for a bit with pin 0x1b (headphone jack), and I could mute it from within hda-analyzer, so I know the program worked. The hda-jack-retask didn't do anything on my computer, or rather, I couldn't verify that retasking actually took place. I even tried to retask the headphone jack (that I know works) as a microphone jack, and that didn't work at all. Maybe I'm not using it right, or maybe the codec doesn't support retasking the front jacks...

So, right now I am at a loss. I have a feeling that the hardware is having the actual green jack pin be something else than what is reported to the codec. I'm not sure where to go on from here. I guess the next step would be to dive into the kernel sources (like patches_realtek.c), and start messing with pin configurations. At this point, about the only thing I know is that I may not get another Gigabyte board (they are unwilling to help with this at all). Still, since I'm not the only one with this problem in the Linux community, a work around (other than using another jack) would be great. I'm sure that the Realtek drivers for Windows have it, but I can't imagine reverse engineering those being feasible at all. Any input from the community? Any more information anyone would be interested in? If I find anything in the meantime, I'll post it here again.

----------

## Navar

Hi gemarcano,

Sorry to hear about your troubles with the UD5H.  I seem to have gotten luckier with my purchase timing (Nov. 2012 from Newegg) of this board and have the 1.1 revision print.  What you might have read are capacitor cap colors differentiating 1.0 vs 1.1 (blue vs purple) respectively.  Not the first time I've ran into revision issues on motherboards and a reason I sometimes force myself to wait awhile on newer chipsets.  Have you tried getting Gigabyte to comply with either correcting your board or exchanging for a revised 1.1?  Obviously, they are correcting somewhere (perhaps the BIOS tables) for that jack working fine within Windows.  Unfortunately, I have no easy way to test for your particular situation.  Which BIOS version are you using currently btw?  I obtained two of these boards, one had F14, the other I updated from F8 or thereabouts.

The only sound difficulties I've had have been getting mic input functional within gnome2.  If you run into same, emerge sndpeek (real-time sound visualization) to keep yourself feeling more sane that it is there and working.  I was somehow able to resolve this by rebuilding my kernel modular for sound instead of builtin, which was very odd given going back to the same builtin kernel would suddenly work too.  Odd and not a problem I can reproduce on the fixed system.  Definitely a configuration issue somewhere in alsa, perhaps gconf or worse udev (I hope not).  Starting with a new user to get shiny new default config files for gnome2 didn't resolve.

I had the same board purchased for a family member and only recently fought with making a microphone functional within gnome2 on it as well.  Same deal, microphone input shows definitely in sndpeek with builtin, although converting to all modules for sound didn't magically resolve the problem on the gnome2 side.  They only have stereo desktop speakers and the green jack output has worked fine.

Everything I'm using is still analog 5.1, so no digital sound tested yet (although I wasn't left any impressions of issues there, unlike the green audio jack you mention which seemed primarily to affect mac x86 users.

----------

## Navar

Hi gemarcano,

Correction.  I do have access to a 1.0 revision of the Gigabyte UD5H motherboard.  Sound is functioning from the green rear input jack.  Let me know if you wanted to see my working kernel config.  Right now it's a little messy (printk/debug, etc.) due to trying to resolve alsa/gnome fighting me on mic input.

----------

## _______0

 *gemarcano wrote:*   

> ISupposedly messing around with some resistors on the motherboard would fix the problem. The thing is, the issue is workaround-able since Windows audio works fine.

 

Crazy, if in windows works fine and linux doesn't and it's related to resistors it could be that linux hda drivers are drawing TOO little power? Just guessing. Can't be UEFI since it's passing the same info to m$$ and linux. It might have to do with power management area within linux.

Do you have a multimeter to measure voltage usage with linux and m$$??

----------

## gemarcano

Navar, thanks for responding. I did hear somewhere that an updated version of 1.0 did not have this problem. I haven't tried the microphone input on my board in Gentoo. I don't use Gnome anyhow, so sorry, I can't verify anything  there. I'll take a look at sndpeek. I hadn't heard of it until now. Yeah, I think from here on out I'm going to be more careful when I buy components. This was my first build, my previous machine being a Gateway 420GR from 2005.

I haven't tried to contact Gigabyte to get it switched, mostly because technically speaking they are not at fault. They do say they do not support Linux. I've contacted their support staff a few times and any time I mention Linux they tell me it's not supported. I tried asking them about known issues, and they just blew me off, in a way.

I am using F14. I think there is a beta for a newer one, but I don't feel like updating it just yet. Maybe over the summer.

I'm not sure how much help your config is going to be, but I'm not going to turn it down. I can always try it and see what happens.

_______0, I'm not sure power draw is a problem here. I know the sound chip supports a low power mode when it's not in use, but the thing is that when it's in use it outputs sound from all other ports except the green one, line out. My guess as to the problem is that the UEFI system is mis-identifying the sound port to the OS on some non-existent hardware pin. Without hardware schematics I can't even begin to guess where the heck the actual problem is on the board. Without reverse-engineering the UEFI ROM I also can't figure out how the motherboard identifies the audio ports and presents them to the OS. Just for kicks I may try to trace some components on the motherboard later. I'm no electronics expert, but I may be able to figure something out. It doesn't hurt to try. I do have a multimeter, but these traces are, for the most part, covered in a protective layer. Thanks for the ideas, though.

----------

## roland.graf

I had the same problem with the same device.

I solved i by enabling the line channel in the Kde-Mixer and turned it on. By default inthe KDE-Mixer the line channel is disabled and the volume is zero. Same is with pcm channels

----------

## gemarcano

Huh, I may have tried this already in alsamixer, but I will try it, thanks for the input.

----------

## Navar

 *gemarcano wrote:*   

> I found some alsa troubleshooting tools, like hda-analyzer [...]. hda-analyzer was useful in helping to see how the codec worked, but I still couldn't figure out how to make sense of the 0x14 pin (green line out). It didn't matter what I tried to do, I couldn't get it to make any sound. I played around for a bit with pin 0x1b (headphone jack), and I could mute it from within hda-analyzer, so I know the program worked. The hda-jack-retask didn't do anything on my computer, or rather, I couldn't verify that retasking actually took place. I even tried to retask the headphone jack (that I know works) as a microphone jack, and that didn't work at all. Maybe I'm not using it right, or maybe the codec doesn't support retasking the front jacks... 

 

I find quite a bit of the ALSA documentation puts me at a loss, often being out of date (still refering to 2.6 kernels in which case codecs like the ALC898 don't even exist), the all-encompassing snd-hda-intel has changed a lot (which is why I have a circa 2006 sigmatel 92xx based laptop that now works worse on exact dB values), alsaconf is/isn't applicable, udev/pam does/doesn't matter (/dev/snd ACLs), etc. and too focused on mentioning changes to aid Pulseaudio working.  Not to mention this is an area where hopefully the Gentoo howto documentation will get a healthy revision because it's in strong need of one.  I think some are still waiting for the dust to settle.

 *Quote:*   

> So, right now I am at a loss. I have a feeling that the hardware is having the actual green jack pin be something else than what is reported to the codec. I'm not sure where to go on from here.

 

Unless the traces are physically rerouted visually on the board (which I never got the impression from any of those hackintosh forums though I cannot reference the removed solder 'fix' to see the actual magic rabbit out of the hat by bonding resistors trick), it seems pretty unlikely.  The BIOS available for both revisions remains the same.  The only true change I was aware of was the extra ethernet chip was revised from Atheros 8151 to 8161.  Also keep in mind as I asserted in another thread here regarding hardware and linux, the hackintosh (which is more fickle than Linux) folk love this board because of how well it does work for them, versus others.  I don't know any vendor yet that builds Intel spec motherboards with perfect Linux support (or really any non-Windows OS), particularly in regards to ACPI or that puts a giant stamp of support approval with the name Linux behind it (remember, ACPI IS and WAS designed and developed in joint part by M$ and Intel).  This has actually been the most trouble free board I've dealt with to date on a build in Windows or Linux while having the most bells and whistles.  You're comparing a Ferrari to a Geo Metro in regards to the innards of your Gateway 420GR (which frankly is some Walmart sold junk).  You didn't make a bad purchase which many major hardware review sites reiterated.  But like all newer hardware, it was imperfect on linux kernels pre-3.4.

My lspci is almost exactly yours with the (expected) exceptions of:

```

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Pitcairn PRO [Radeon HD 7850]

01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cape Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]

04:00.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 41)

06:00.0 Ethernet controller: Qualcomm Atheros AR8161 Gigabit Ethernet (rev 10)

```

More interesting is that you have a nvidia card and I have a newer ATI (7850).  So we both have video card provided HDMI that we're not using to throw in the mix from that.  But, again, the UEFI hasn't caused me issues there on perceived card ordering, with the intel HDA coming in first as 0 and default with ALSA.  The 1.0 board I have access to is just using the integrated Intel HD4000.

```

$ cat /proc/asound/cards

 0 [PCH            ]: HDA-Intel - HDA Intel PCH

                      HDA Intel PCH at 0xf7f30000 irq 46

 1 [HDMI           ]: HDA-Intel - HDA ATI HDMI

                      HDA ATI HDMI at 0xf7e60000 irq 47

$ aplay -L

null

    Discard all samples (playback) or generate zero samples (capture)

default:CARD=PCH

    HDA Intel PCH, ALC898 Analog

    Default Audio Device

sysdefault:CARD=PCH

    HDA Intel PCH, ALC898 Analog

    Default Audio Device

front:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    Front speakers

surround40:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    4.0 Surround output to Front and Rear speakers

surround41:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    4.1 Surround output to Front, Rear and Subwoofer speakers

surround50:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    5.0 Surround output to Front, Center and Rear speakers

surround51:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    5.1 Surround output to Front, Center, Rear and Subwoofer speakers

surround71:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Analog

    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers

iec958:CARD=PCH,DEV=0

    HDA Intel PCH, ALC898 Digital

    IEC958 (S/PDIF) Digital Audio Output

hdmi:CARD=HDMI,DEV=0

    HDA ATI HDMI, HDMI 0

    HDMI Audio Output

hdmi:CARD=HDMI,DEV=1

    HDA ATI HDMI, HDMI 1

    HDMI Audio Output

hdmi:CARD=HDMI,DEV=2

    HDA ATI HDMI, HDMI 2

    HDMI Audio Output

hdmi:CARD=HDMI,DEV=3

    HDA ATI HDMI, HDMI 3

    HDMI Audio Output

```

Tonight I grabbed a copy of the python based hda-analyzer.  This is my own system a 1.1 revision UD5H purchased in mid-November.

Keep in mind, the Realtek ALC898 codec functionality was only recently added to ALSA (as of 1.0.25 around the date of your OP and is the version initially installed to work here in November).  To assert it's any more bug free than the F14 BIOS we're both using is probably a bit of a leap.  It'd also be very strange to have full functionality in Windows XP/7 using the official drivers (as you and I both seem to) vs what you're experiencing and what some (not all) hackintosh folk have.  To me with past and present experiences, ALSA is more suspect.

Now, going back to what you brought up above, node 0x14 PIN is associated to the Front Playback Switch toggle here and associated with the Audio Mixer [0x0c] for the front playback volume under the connection list.  Which is how things are supposed to look and work.  Is this not the case on your end?

In other words, the text dump from mine working looks like the following:

 *Quote:*   

> 
> 
> Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
> 
>   Control: name="Front Playback Switch", index=0, device=0
> ...

 

speaker-test -Dsurround50:PCH -c5  works exactly as you'd expect.  As for the 1.0 system it only has a 2 channel setup, but they're plugged into the green line out Front jack and work as expected.

I'll have to get back to you if your settings substantially differ once I have access to the 1.0 board to check hda-analyzer there.  Specifically check node 0x0c and let me know if it does not have Front Playback Volume set on it, or even better that it shows Amp-Out vals higher than 0x00 and unmuted, node 0x14 shows a connection 0x0c* mapping to it and that 0x14 is also showing enabled.  Best would be to post the test dump portions of each here so myself and others can see.

----------

## Navar

Gemarcano,

I'm at the 1.0 revision UD5H system today.  HDAAnalzyer values for Nodes 0x0c (front audio line out volume mixer) and 0x14 (front audio switch) were the same as the 1.1 system.  I took some photos if you ended up needing to see them.  The 1.0 system here has uniform spacing between memory slots with printing after them on right side.  Caps are also purple label (like the 1.1 revision board) than the blue ones depicted here.

If your board looks exactly like the one depicted there on the small gap with printing between the memory slots, then you may want to press Gigabyte for an RMA, though I still suspect this is an ALSA issue.

First though, I'm more than curious if your node values from hdaanalyzer were the same.

Here are the kernel 3.7-10-r1 (will update it today for 3.8) CONFIG_SND settings currently in use on this 1.0 revision board and work fine:

```

# zcat /proc/config.gz | grep -i snd | grep -v "not set"

CONFIG_SND=m

CONFIG_SND_TIMER=m

CONFIG_SND_PCM=m

CONFIG_SND_HWDEP=m

CONFIG_SND_SEQUENCER=m

CONFIG_SND_SEQ_DUMMY=m

CONFIG_SND_OSSEMUL=y

CONFIG_SND_MIXER_OSS=m

CONFIG_SND_PCM_OSS=m

CONFIG_SND_PCM_OSS_PLUGINS=y

CONFIG_SND_SEQUENCER_OSS=y

CONFIG_SND_HRTIMER=m

CONFIG_SND_SEQ_HRTIMER_DEFAULT=y

CONFIG_SND_DYNAMIC_MINORS=y

CONFIG_SND_SUPPORT_OLD_API=y

CONFIG_SND_VERBOSE_PROCFS=y

CONFIG_SND_VERBOSE_PRINTK=y

CONFIG_SND_DEBUG=y

CONFIG_SND_VMASTER=y

CONFIG_SND_KCTL_JACK=y

CONFIG_SND_DMA_SGBUF=y

CONFIG_SND_DRIVERS=y

CONFIG_SND_PCI=y

CONFIG_SND_HDA_INTEL=m

CONFIG_SND_HDA_PREALLOC_SIZE=64

CONFIG_SND_HDA_HWDEP=y

CONFIG_SND_HDA_CODEC_REALTEK=y

CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0

CONFIG_SND_USB=y

CONFIG_SND_FIREWIRE=y

```

----------

## gemarcano

Roland.graf, I tried what you suggested with the line channel in Kde-mixer, and sadly that didn't do anything.

Navar, forgive my untimely responses, and thank you for your help and information thus far. I haven't had time lately to work on tinkering with my computer lately.

I took a look at your text output/description of the 0x14 and 0x0c pins, and I noticed two differences. The first one is for "dir=1" in yours-- mine reads "dir=OUT," but I think these are probably the same. The second difference, though, may be significant. In the 0x0c pin, you have the line "Amp-Out vals: [0x51 0x51]" while mine reads "Amp-Out vals:  [0x46 0x46]." Your kernel config there looks a lot like mine. I have a few things extra (that I may prune out), but otherwise looks the same. My motherboard sounds just like the one you have-- purple caps and the spacing of the memory being equal.

I think for starters, I'm going to look at why my Amp-Out values are different from yours. Well, I have no more leads after that, but hey, it's better than nothing.

After all is said and done, I have to agree with you that this board combination has given me little trouble in terms of hardware (except sound), compared to other systems I have worked with. I may have been rash with my prevous statement of not buying another board from Gigabyte. I just wish they would support Linux based operating systems.

Once again, thanks for your help, and I will report back if I find anything new. I haven't used Gentoo in quite some time, so I'm updating the system. Thankfully this build is incredibly fast, so it won't take too long.

EDIT: I just played around with HDAAnlayzer, and it seems the Amp-Out vals have to do with volume information. I was able to tweak them to match your values, and I was unable to produce sound. That having been said, I'm unable to run speaker-test right now, something about "Error in `speaker-test': free(): invalid next size (fast): ..." . I'll keep trying things and probably re-emerge a few packages.Last edited by gemarcano on Sun Jun 23, 2013 3:16 am; edited 1 time in total

----------

## Navar

 *gemarcano wrote:*   

> I took a look at your text output/description of the 0x14 and 0x0c pins, and I noticed two differences. The first one is for "dir=1" in yours-- mine reads "dir=OUT," but I think these are probably the same. The second difference, though, may be significant. In the 0x0c pin, you have the line "Amp-Out vals: [0x51 0x51]" while mine reads "Amp-Out vals:  [0x46 0x46]." Your kernel config there looks a lot like mine. I have a few things extra (that I may prune out), but otherwise looks the same. My motherboard sounds just like the one you have-- purple caps and the spacing of the memory being equal.
> 
> 

 

I would look into the dir=1 vs dir=OUT difference and perhaps trimming the kernel config some (extra unrelated codecs, e.g.).  There's nothing wrong with your Amp-Out values (volume) so you can ignore that discrepancy.  You're quite welcome and please do post a followup if you resolve this.  There are many people (outside of Gentoo) who may benefit from the result.

----------

## Navar

Correction.  ControlAmp: dir=Out portions are seen on /proc/asound/card0/codec#2 information here (which is or should be essentially the same as the text tab portion of that python program for a given node).

Please post a pastebin of your /proc/asound/card0/codec files.  On the 1.0 system here they are codec2 and 3 but your setup may number differently.

Since you seem to have the same hardware, it should be possible to resolve this.

What does equery l -f "^.*alsa.*$"  show?

Which kernel are you at currently?  Gentoo sources 3.8.13?  Are you keyworded amd64 or ~amd64?

As an aside, the mic input issue I mentioned earlier in the thread was interesting.  sndpeek would show microphone input as expected by rear/front mic boost and capture input volume seeings.  Arecord and anything in gnome2 did not.  The 'Digital' slider for whatever reason on the capture portion of alsamixer affects the analog recording volume like a multiplier with 0 effectively muting.  I didn't want very much (a value of about 15 with boost at 22) otherwise there would be excessive noise.

----------

## gemarcano

Navar, sorry for the hiatus, and I hope you're still around to help. I finally have more time to try to see what is up with this computer. I'm also a bit more focused on Gentoo since I'm also trying to install it into a new laptop (UEFI is a royal pain).

I'll be posting the information you requested momentarily.

----------

## gemarcano

Here's the pastebin you requested: http://pastebin.com/ekXXTE5N

Here's equery l -f "^.*alsa.*$":

```
equery l -f "^.*alsa.*$"

 * Searching for ^.*alsa.*$ ...

[IP-] [  ] media-libs/alsa-lib-1.0.27.2:0

[IP-] [  ] media-plugins/gst-plugins-alsa-0.10.36:0.10

[IP-] [  ] media-sound/alsa-utils-1.0.27.2:0.9
```

I'm using kernel 3.10.7 right now in unstable ~amd64.

----------

