Contribute
Register

ALC888b without old AppleHDA.kext possible? [SOLVED]

Status
Not open for further replies.
adamsmasher said:
Does the BIOS update need to be installed from windows?
No, you can also put it on a USB Stick/HD and use Qflash from Bios startup
 
longtom said:
adamsmasher said:
Does the BIOS update need to be installed from windows?
No, you can also put it on a USB Stick/HD and use Qflash from Bios startup

But you'll have to extract it first using 7zip as it is a self-extracting executable.

Other than updating the BIOS, where exactly would I have to put the AppleHDA.kext (the 179.1.4 one)? In /E/Extensions or in the Library folder? Does it have to be the only AppleHDA.kext in the system? And where to put the DSDT.aml, in the root folder of my system partition, right? And only the .aml, not the .dsl, correct?

Am trying to get sound to work, I had it before, right after updating the BIOS and before rebooting with the 10.6.2 AppleHDA.kext... strange.

edit: Ok, works now after removing and re-installing AppleHDA.kext (10.6.2). However, I still get numerous errors pertaining to this kext during the boot process, is this normal?
 
thelostswede said:
And in this specific case it obviously adds something that would improve the functionality of your hackingtosh, but you're too scared to update to it?
Actually, no, I'm not "too scared" to update it. I've already updated my BIOS from F3 to F5. Also, it really isn't adding functionality. It's only really needed if you want your hackintosh to be more vanilla.
thelostswede said:
There's nothing missing, it's just not what they've deemed to be final versions, as they're still tweaking a few things here and there.
From Gigabyte's website:
Gigabyte's Website said:
What is a BETA?
BETA describes a new version that is reliable yet may not include all the features of the final product. During this phase we are previewing new features and gathering customer input to insure our product provides the best experience possible.
thelostswede said:
I'm not meaning to be rude here, but you're being overly cautious about something that won't cause any damage. Even more so as Gigabyte boards have a pair of BIOS chips, so even if something would go wrong, there's a backup BIOS on the board.
Yea Gigabyte's boards have two BIOS chips, but what if when you flash, something in both of the BIOS's gets screwed up? Or am I just misunderstanding DualBIOS? IMO, the less times I have to flash my BIOS, the better.

Also, next time instead of getting mad by the fact that I am being "too cautious", how about you just inform me of my possible misunderstandings because addressing the situation like you just did, just makes you sound like an idiot.

Edited for code error.
 
Cantello said:
edit: Ok, works now after removing and re-installing AppleHDA.kext (10.6.2). However, I still get numerous errors pertaining to this kext during the boot process, is this normal?

I get these same errors. So I guess it means that it is normal :D Hopefully we can figure out a way to fix this.
 
The errors are 'normal'- I think they have to do with the LegacyHDA kext. Our next project should be to eliminate these audio error messages in the login, although it has nothing to do with performance, it will make the startup faster.

I think it's a matter of the way the LegacyHDA kext interacts with the AppleHDA kext. Here's the relevant parts of my startup messages from System Profiler/Logs/Kernel Logs

Code:
Jan 25 23:16:57 localhost kernel[0]: Not loading kext com.apple.driver.AppleHDAController - not found and kextd not available in early boot.
--- (deleted stuff)
Jan 25 23:16:58 Home kernel[0]: Sound assertion "0 == pciVendorProductID" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDAController/AppleHDAController.cpp" at line 2682 goto Exit
--- (deleted stuff)
Jan 25 23:17:07 Home kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDAWidget.cpp" at line 3641 goto handler
Jan 25 23:17:07 Home kernel[0]: Sound assertion "0 != widget->setUnsolicited ( true )" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDACodecGeneric.cpp" at line 989 goto handler
Jan 25 23:17:07 Home kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDAWidget.cpp" at line 3641 goto handler
Jan 25 23:17:07 Home kernel[0]: Sound assertion "0 != widget->setUnsolicited ( true )" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDACodecGeneric.cpp" at line 989 goto handler
Jan 25 23:17:07 Home kernel[0]: Sound assertion "0 != result" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDAWidget.cpp" at line 3641 goto handler
Jan 25 23:17:07 Home kernel[0]: Sound assertion "0 != widget->setUnsolicited ( true )" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDACodecGeneric.cpp" at line 989 goto handler
 
Evildemon989 said:
Yea Gigabyte's boards have two BIOS chips, but what if when you flash, something in both of the BIOS's gets screwed up? Or am I just misunderstanding DualBIOS? IMO, the less times I have to flash my BIOS, the better.

Also, next time instead of getting mad by the fact that I am being "too cautious", how about you just inform me of my possible misunderstandings because addressing the situation like you just did, just makes you sound like an idiot.

Yes, you misunderstood how dual BIOS works, as you only flash the primary BIOS chip, not the secondary. The second chip is just there as a backup and retains the original BIOS. There's nothing wrong with flashing your BIOS and these days there really is very little that can go wrong. Back in the days it was possible to recover a badly flashed board via a special command in the autoexec.bat file and renaming the flash file even if the board was more or less dead.

And thank you for calling me names, I wasn't mad, I just think you should do some research before you go and post things, especially when it's something you obviously don't know enough about.
 
thelostswede said:
Yes, you misunderstood how dual BIOS works, as you only flash the primary BIOS chip, not the secondary. The second chip is just there as a backup and retains the original BIOS.
Alright, that does make sense.

And thank you for calling me names, I wasn't mad, I just think you should do some research before you go and post things, especially when it's something you obviously don't know enough about.
Even if they are still "tweaking and a few things here and there", isn't it feasible that there could still be a few stability issues that people who have install the BIOS update have found that the internal testers didn't? It's not out of the realm of possibility.
 
Well, possible, but I have had none over the past I don't know how many years. At times I've been running beta BIOSes for months, as the final version took forever to come out. At the end of the day its your call, but you really are worrying about something that isn't an issue. Besides, who knows, maybe the "fix" this feature in the final BIOS and it won't work the way it does now. I've actually had less features after a BIOS upgrade in the past as Gigabyte changed the way they did their BIOSes for their P35 boards, so go figure...
 
Everything is working, except the the "Type" values are things like "DevShortNameSpkr", etc. Used to be "Built-in Speaker". Is this happening to any of you? Thx!
 
yes this is happening to me as well. probably shouldn't be too hard to fix as it is just cosmetic.

on a side note, is there any way to set up surround sound with this set-up? it seems like we can only use two outputs at a time. perhaps i am wrong.

--Nick
 
Status
Not open for further replies.
Back
Top