Contribute
Register

Asus Q301LA-bsi5t17 (S301LA) – Yosemite Clover Install

Status
Not open for further replies.
Hmm.. I don't know of a way to fix the headphone problems with layout/platforms... Unless you sent verbs via AppleHDAHardwareConfigDriver. But that would only work for bootup not work for after sleep/wake...

But it could be your codec doesn't have the headphone issue...


it did have a headphone issue. One where it seems like I hear double it was a weird problem that I'm not sure how to describe.
Anyways, my hack fix which I found accidentally was to use the same verb twice. I forget all the details. I'd have to get into the verbs again.
 
it did have a headphone issue. One where it seems like I hear double it was a weird problem that I'm not sure how to describe.

It sounds similar to the problem I had...

Anyways, my hack fix which I found accidentally was to use the same verb twice. I forget all the details. I'd have to get into the verbs again.

Sending the same verb twice would probably have no effect. Verbs are essentially used to set registers in the HDA/codec. Setting the same setting twice would have no more effect than sending it once. There are exceptions (Double Function Group Reset, for example), and so it would depend on the specifics of what you did.

At any rate, you can probably use CodecCommander for this sort of thing... and if your codec is similar to other ALC233, it will probably "just work."

To come up with real/understandable solutions, it is necessary to become familiar with the Intel HDA spec, such that you understand what a verb is and what they can do.

Side note: Prior to understanding more of the HDA spec, I'd always be somewhat confused as to what the heck was going on with the AppleHDAHardwareConfigDriver "verbs"... But it all makes sense when you realize that these verbs are setting the DefaultConfig for nodes. The config data is basically used to describe the node... and the purpose of writing over the defaults is to change what AppleHDA will see when it initializes. What you find out from the HDA spec, is that these descriptors are 32-bit and have to be set one byte at a time (with different verbs) because the payload for most verbs is only 8-bit. No guide I ever read, explained it that way, and perhaps it is not a good way to explain it to a non-programmer...
 
It sounds similar to the problem I had...



Sending the same verb twice would probably have no effect. Verbs are essentially used to set registers in the HDA/codec. Setting the same setting twice would have no more effect than sending it once. There are exceptions (Double Function Group Reset, for example), and so it would depend on the specifics of what you did.

At any rate, you can probably use CodecCommander for this sort of thing... and if your codec is similar to other ALC233, it will probably "just work."

To come up with real/understandable solutions, it is necessary to become familiar with the Intel HDA spec, such that you understand what a verb is and what they can do.

Side note: Prior to understanding more of the HDA spec, I'd always be somewhat confused as to what the heck was going on with the AppleHDAHardwareConfigDriver "verbs"... But it all makes sense when you realize that these verbs are setting the DefaultConfig for nodes. The config data is basically used to describe the node... and the purpose of writing over the defaults is to change what AppleHDA will see when it initializes. What you find out from the HDA spec, is that these descriptors are 32-bit and have to be set one byte at a time (with different verbs) because the payload for most verbs is only 8-bit. No guide I ever read, explained it that way, and perhaps it is not a good way to explain it to a non-programmer...


now how to take that info and figure out a fool proof way to either patch applehda or auto config a dummyhda type kext.
 
now how to take that info and figure out a fool proof way to either patch applehda or auto config a dummyhda type kext.

Some automation is possible, but not sure all... Sometimes you need a human brain to intervene.
 
it did have a headphone issue. One where it seems like I hear double it was a weird problem that I'm not sure how to describe.
Anyways, my hack fix which I found accidentally was to use the same verb twice. I forget all the details. I'd have to get into the verbs again.

Try this:
Go to Audio Midi Setup and and select mute
one of the canals your headphones.
 
Try this:
Go to Audio Midi Setup and and select mute
one of the canals your headphones.

I had a similar problem with ALC283 on my Lenovo u430... Actually there were a few problems:

- EAPD problem (this is easy, I mention it for completeness): Fixed by CodecCommander.kext to update EAPD bit on EAPD capable nodes on wake from sleep.

- Problem with muffled headphone: Moving the balance to either all right, or all left made it sound ok (but still mono). The fix here was to use CodecCommander (Custom Commands) to send verb SET_WIDGET_CONTROL 0x25 to node 0x19 (has to do with headphone output enabling), verb 0x01970725.

- Problem with audio being disabled after entering D3cold post-sleep/wake: Fixed by using CodecCommander.kext "Perform Reset"=true. This caused another problem: lost jack sense for headphones. Doing a reset (Perform Reset does a Double Function Group Reset), caused jack sense to fail for headphones, below...

- Lost jack sense with "Perform Reset"=true: Fixed by using CodecCommander.kext (Custom Commands) to send verb SET_UNSOLICITED_ENABLE 0x83 to node 0x21 (headphone), verb 0x02170883.

These fixes have proved pretty common (nodes ids can vary). So far same/similar fixes for ALC269, ALC233, ALC255, ALC233. Similar fixes were already in the kext for ALC668 and ALC292.
 
Your ALC283 has a jack combo?
it works?

It is some sort of headphone/external mic jack. It works as far as the headphones with correct jack sense (with the fixes in CodecCommander previously mentioned). By default the mic part seems to be disabled in Windows, although maybe it can be enabled.

I don't have a headset and/or mic to test with.

I'm pretty sure the Platforms/layout that I'm using is not correct for using the external mic.
 
It is some sort of headphone/external mic jack. It works as far as the headphones with correct jack sense (with the fixes in CodecCommander previously mentioned). By default the mic part seems to be disabled in Windows, although maybe it can be enabled.

I don't have a headset and/or mic to test with.

I'm pretty sure the Platforms/layout that I'm using is not correct for using the external mic.

I tested both windows as in Linux Ubuntu 15.04
in both the ComboJack works well, but not on OSX
I extracted a new codec_dump Linux Unbuntu 15.04
and now I can see Mic Jack the node 0x19.
I made the changes but without success yet, perhaps with
these corrections in CodecCommander can have some success
although everything should work with the patches on AppleHDA.
 
...
although everything should work with the patches on AppleHDA.

There is certain things you can't do within the confines of AppleHDA...
 
Status
Not open for further replies.
Back
Top