| View previous topic :: View next topic |
| Author |
Message |
gemarcano
Tux's lil' helper
Joined: 04 Jun 2012
Posts: 100
Location: California
|
 Posted: Sun May 19, 2013 3:13 am Post subject: |
 |
|
| Huh, I may have tried this already in alsamixer, but I will try it, thanks for the input. |
|
| Back to top |
|
 |
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Tue May 28, 2013 7:01 am Post subject: |
|
|
| 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:
| Code: |
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.
| Code: |
$ 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
ControlAmp: chs=3, dir=1, idx=0, ofs=0
Control: iface="card", name="Line Out Front Jack", index=0, device=0
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x0001003c: IN OUT HP EAPD Detect
EAPD 0x2: EAPD
Pin Default 0x01014410: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Green
DefAssociation = 0x1, Sequence = 0x0
Pin-ctls: 0x40: OUT
Unsolicited: tag=0x02, enabled=1
Power: setting=D0, actual=D0
Connection: 5
0x0c* 0x0d 0x0e 0x0f 0x26
Node 0x0c [Audio Mixer] wcaps 0x20010f: Stereo Amp-In Amp-Out
Control: name="Front Playback Volume", index=0, device=0
ControlAmp: chs=3, dir=1, idx=0, ofs=0
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x00 0x00]
Amp-Out caps: ofs=0x57, nsteps=0x57, stepsize=0x02, mute=0
Amp-Out vals: [0x51 0x51]
Connection: 2
0x02 0x0b
|
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.
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Sun Jun 02, 2013 12:07 am Post subject: |
|
|
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:
| Code: |
# 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
|
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
| Back to top |
|
|
gemarcano
Tux's lil' helper
Joined: 04 Jun 2012
Posts: 100
Location: California
|
| Posted: Sat Jun 22, 2013 9:42 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Sun Jun 23, 2013 1:52 am Post subject: |
|
|
| 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.
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 353
|
| Posted: Sun Jun 23, 2013 5:23 am Post subject: |
|
|
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.
_________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. |
|
| Back to top |
|
|
gemarcano
Tux's lil' helper
Joined: 04 Jun 2012
Posts: 100
Location: California
|
| Posted: Wed Aug 21, 2013 12:55 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
gemarcano
Tux's lil' helper
Joined: 04 Jun 2012
Posts: 100
Location: California
|
| Posted: Wed Aug 21, 2013 1:01 am Post subject: |
|
|
Here's the pastebin you requested: http://pastebin.com/ekXXTE5N
Here's equery l -f "^.*alsa.*$": | Code: | 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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
