Contribute
Register

Any fix to the Garbled/Distorted Headphone issue?

Status
Not open for further replies.
I see... so without a working voodoohda headphone, its almost impossible to fix the applehda is what you are saying...

Ill poke around and make sure I have the latest build
 
mybeatsarebetter said:
I see... so without a working voodoohda headphone, its almost impossible to fix the applehda is what you are saying...

Ill poke around and make sure I have the latest build
Click to expand...

Well, I don't know about impossible. Maybe a way to look at the widget control in Linux... I didn't have to go down that path because VoodooHDA+CodecCommander was working.
 
Sofar the only change that I have seen required is in enable / vref-in.
See Intel HDA Specification, 7.3.3.13.

I never had a working configuration to compare with my Dell, so I just went over the specification to understand it in great detail.

In Rehabman's latest CodecCommander build there are the following combinations:

Code: 
               76543210
ALC283:        
0x19 707 25 -> 00100101 -> In Enable, VrefEn, EPT = 1
0x21 707 C0 -> 11000000 -> Headphone Enable, Out Enable


ALC292:
0x1A 707 24 -> 00100100 -> In Enable, VrefEn


ALC668:
0x1B 707 20 -> 00100000 -> In Enable

Just check your path to see which nodes are on the headphone path, check their output with hda-verb.
After that you should be able to determine which one requires to be enabled.
 
the-darkvoid said:
Sofar the only change that I have seen required is in enable / vref-in.
See Intel HDA Specification, 7.3.3.13.

I never had a working configuration to compare with my Dell, so I just went over the specification to understand it in great detail.

In Rehabman's latest CodecCommander build there are the following combinations:

Code: 
               76543210
ALC283:        
0x19 707 25 -> 00100101 -> In Enable, VrefEn, EPT = 1
0x21 707 C0 -> 11000000 -> Headphone Enable, Out Enable


ALC292:
0x1A 707 24 -> 00100100 -> In Enable, VrefEn


ALC668:
0x1B 707 20 -> 00100000 -> In Enable

Just check your path to see which nodes are on the headphone path, check their output with hda-verb.
After that you should be able to determine which one requires to be enabled.
Click to expand...

I experimented also with 0x20 for node 0x19. That worked too. So not sure if the VrefEn or EPT are needed in my case. But they were set with Voodoo, so I used that value. I haven't looked to see if Voodoo sets these values explicitly or the result from state after reset.

I think my setting of 0xC0 to 0x21 is also not necessary (still experimenting). Node 0x19 is not on any path map, so I'm a little confused as to how one would know that node needs tweaking. Although it does have connections in the Linux dump to other nodes that are on the pathmaps. Further contributing to mystery, it is described as an external mic jack in the Linux dump. Why a widget config on a Mic affects the headphone is a mystery.

Note also there is some sort of strange overlap between VrefEn and and EPT that is not clear in the spec (they seem to both use the same bits). For example, setting VRefEn to 001b or 010b (50%/Ground) will set EPT encoding 01b/10b which are marked "Reserved". It does say EPT is specific to "associated digital Pin Widget", so perhaps this overlap is explained that VrefEn would not apply to such a widget. It also states that valid values for VRefEn are dependent on the PinCaps, so presumably a PinCap for a digital pin widget would not contain any valid VRefEn values.

If you go down this path, you should plan on reading plenty and being mystified the entire way...
 
the-darkvoid said:
Sofar the only change that I have seen required is in enable / vref-in.
See Intel HDA Specification, 7.3.3.13.

I never had a working configuration to compare with my Dell, so I just went over the specification to understand it in great detail.

In Rehabman's latest CodecCommander build there are the following combinations:

Code: 
               76543210
ALC283:        
0x19 707 25 -> 00100101 -> In Enable, VrefEn, EPT = 1
0x21 707 C0 -> 11000000 -> Headphone Enable, Out Enable


ALC292:
0x1A 707 24 -> 00100100 -> In Enable, VrefEn


ALC668:
0x1B 707 20 -> 00100000 -> In Enable

Just check your path to see which nodes are on the headphone path, check their output with hda-verb.
After that you should be able to determine which one requires to be enabled.
Click to expand...


Check them where....I'm confused, I have a different codec than all three of the ones you posted, how would codec commander know to look for my build?

whats the node?
 
RehabMan said:
You first need to determine which widget nodes need modification. You use CodecCommanderClient (installed as hda-verb with 'make install') to determine what needs to change. After you determine the widget node that needs to be set after sleep, you can make the necessary Info.plist changes.

I added some scripts to the repo today based on stuff that the-darkvoid provided. They are simple scripts that run hda-verb for all nodes...

Check out the repo: https://github.com/RehabMan/EAPD-Codec-Commander

Here's an overview of what I did:

- installed and got VoodooHDA to work (built from latest sources, fixed bugs, etc.)
- noticed that no headphone problem with VoodooHDA
- used widget_dump.sh to look at the widget values
- set everything back for patched AppleHDA
- verified headphones still a problem
- used widget_dump.sh to look at widget values
- compared the two dumps (VoodooHDA vs. AppleHDA dump)
- started poking around with hda-verb to set the pini widgets control
- for example, I noticed that pin widget for node 0x19 was 0 with AppleHDA, but 0x25 with VoodooHDA, so with AppleHDA (headphone problematic):
Code: 
  hda-verb 0x19 SET_PIN_WIDGET_CONTROL 0x25
- tested headphones... and at that point they were working

And all that led to what is now in the checked in Info.plist for CodecCommander, Realtek ALC283 profile.

I'm not sure how you'd stumble into the right setup without having a working configuration (in my case, VoodooHDA) that you can read the HDA configuration from. It would take a lot of trial/error (or reading the HDA spec) to figure out that node 0x19 needs to be 0x25.

Maybe there is a way to read HDA pin widget control (or other settings) in Linux?

Note: I did a fair bit of reading of the Intel HDA spec.... That way I knew what an HDA verb was, what a node was, etc.
Click to expand...

Hi Rehabman,

I tried your command "hda-verb 0x19 SET_PIN_WIDGET_CONTROL 0x25" and it works!! It solves the headphone issue. I modified the codeccommander.kext info.plist exactly as yours. Now everything is working properly. =] Thanks a lot!
 
mybeatsarebetter said:
Check them where....I'm confused, I have a different codec than all three of the ones you posted, how would codec commander know to look for my build?

whats the node?
Click to expand...

If you have alc255, the configuration is actually same as Rehabman's one.
 
mybeatsarebetter said:
Check them where....I'm confused, I have a different codec than all three of the ones you posted, how would codec commander know to look for my build?

whats the node?
Click to expand...

The pathmaps are in your patched AppleHDA Platforms.xml.zlib files. Do some reading on how to patch AppleHDA and you'll understand more.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top