EDIT: The thread below seems to be only an issue for EFI installs of Windows 8 RTM. I can't get audio working on my rMBP on Windows 8 RTM x64 after installing bootcamp drivers. In device manager I get one working 'High Definition Audio Controller' and one non functional. I think the functional is for the HDMI audio.
- Xbib-u-dev Rev 3 Drivers For Mac Download
- Xbib-u-dev Rev 3 Drivers For Mac Pro
- Xbib-u-dev Rev 3 Drivers For Mac Free
The non-functional has the following properties. Location: PCI bus 0, device 27, function 0 Driver Provider: Microsoft Driver Date: 7/25/2012 Driver Version: 6.2.9200.16384 Digital Signer: Microsoft Windows and reports the following events. Device PCI VEN8086&DEV1E20&SUBSYS72708086&REV04 3&11583659&0&D8 had a problem starting. Driver Name: hdaudbus.inf I have tried the following: removing and deleting the current driver (always reinstalls) reinstalling the realtek driver from the bootcamp disk (doesn't take) I notice that the usetup.iss file from the realtek folder that book camp leaves lists the following entry. Name=Realtek High Definition Audio Driver Version=2.49.but theRtlUpd64.exe file property details list the product version as 2,8,0,6 with a modified date of 5/4/2012.and the website from which I downloaded them lists them as 2.70 Autoupdate won't replace the driver. I could try to manually install the driver but there are 42 inf files in the Realtek High Definition Audio Controller file I downloaded, none of which are called hdaudbus.inf. I tried deleting all the entries of hdaudbus.inf but TrustedInstaller won't let me delete the copy in WinSxS.
Anyone else have this working? Any chance this is an Intel C216 audio controller and if so, why would the realtek drivers be included or get installed at all?
Click to expand.Two interesting things appear on the online Intel Driver Update Utility when checking this rMBP under Windows 8. The utility shows the Chipset driver is current even though released in November of 2011. And it shows that the driver associated with the Intel Desktop board is the NVIDIA driver. Since the NVIDIA High Definition Audio is functional using its own driver, it isn't obvious whether. the utility is broken and simply thinks the driver for the first High Definition Audio device (the NVIDIA one) is associated with the Intel device or. whether the reason the Intel device won't start is because although device manager shows the Microsoft hdaudbus driver it really is trying to use the NVIDIA driver or.
something else entirely Here are the utility results. Intel Chipset Software Installation Utility (Chipset INF) Product Detected Current Version Installed 9.3.0.1019 This version is valid. Audio Driver for Intel Desktop Board Product Detected NVIDIA High Definition Audio Current Driver Installed 1.3.11.1 This device is unknown or unsupported. Please contact the manufacturer for possible updates. Yes 1e20 isn't a thunderbolt controller. I was thinking that maybe the difference between BD82C216 and E208B284 was embedded Thunderbolt support but I see in the teardown that the rMBP has the dedicated DSL3510L Thunderbolt controller. Thanks for your help terraphantm. Intel Chipset Software Installation Utility (Chipset INF) Product Detected Current Version Installed 9.3.0.1019 This version is valid.
Audio Driver for Intel Desktop Board Product Detected NVIDIA High Definition Audio Current Driver Installed 1.3.11.1 This device is unknown or unsupported. Please contact the manufacturer for possible updates. Yes 1e20 isn't a thunderbolt controller. I was thinking that maybe the difference between BD82C216 and E208B284 was embedded Thunderbolt support but I see in the teardown that the rMBP has the dedicated DSL3510L Thunderbolt controller. Thanks for your help terraphantm. Click to expand.I ran the chipset identification utility in windows PE. Wasn't very helpful.
All it said was that it was an 'Intel 6-series Chipset' What I can tell you is that when I enumerate the PCI devices in OSX, 1023:4206 does not appear at all - but 8086:1E20 does. That indicates that perhaps my theory is correct in that Apple maps the onboard audio as a Cirrus Logic controller through the CSM. However, if there is a proper windows driver for the Intel controller, I don't see why we can't install that.
But it may need to be updated for Windows 8. Best bet might be to see if there are PC manufacturers that use the same controller, and if so, see if any of those guys are able to get audio to work in Windows 8. Edit: Actually. It looks like there might be a Cirrus Logic controller on board. I can't tell for sure, but if you look at, you can see a tiny chip all the way on the right side that they didn't bother identifying.
I can't read it, but it looks very similar to the (highlighted in teal). I ran the chipset identification utility in windows PE. Wasn't very helpful. All it said was that it was an 'Intel 6-series Chipset' What I can tell you is that when I enumerate the PCI devices in OSX, 1023:4206 does not appear at all - but 8086:1E20 does. That indicates that perhaps my theory is correct in that Apple maps the onboard audio as a Cirrus Logic controller through the CSM. However, if there is a proper windows driver for the Intel controller, I don't see why we can't install that.
But it may need to be updated for Windows 8. Best bet might be to see if there are PC manufacturers that use the same controller, and if so, see if any of those guys are able to get audio to work in Windows 8. Click to expand.I was hoping that Intel would have the drivers but there is no Intel 6-series Chipset listed here and of course the rMBP is using a C216 modified chipset which is really a 7-series and no 7-series are listed at all. It is possible that Intel is OEMing the Cirrus Logic for its chipset.
The CirrusAPOx64.dll driver in Bootcamp shows file properties version of 1.0.1.19, a modified date of 6/13/2012 and a file size of 73.3 kb. The same file from Cirrus (CS4207WinVistaWin732-64-bit6-6001-1-30) shows the same version number 1.0.1.19, but a modified date of 8/16/2010 and a file size of 67.5 kb.
I understand the Cirrus CS420x is a modified verison of the CS4207. I think your instinct is right about chasing either Intel and or Cirrus OEMs to see if they publish later drivers. Seems like an especially big pain on the Cirrus side when the version numbers aren't updated. I was hoping that Intel would have the drivers but there is no Intel 6-series Chipset listed here and of course the rMBP is using a C216 modified chipset which is really a 7-series and no 7-series are listed at all.
It is possible that Intel is OEMing the Cirrus Logic for its chipset. The CirrusAPOx64.dll driver in Bootcamp shows file properties version of 1.0.1.19, a modified date of 6/13/2012 and a file size of 73.3 kb. The same file from Cirrus (CS4207WinVistaWin732-64-bit6-6001-1-30) shows the same version number 1.0.1.19, but a modified date of 8/16/2010 and a file size of 67.5 kb. I understand the Cirrus CS420x is a modified verison of the CS4207. I think your instinct is right about chasing either Intel and or Cirrus OEMs to see if they publish later drivers. Seems like an especially big pain on the Cirrus side when the version numbers aren't updated. Click to expand.The intel device just controls an HDAudioBus that the real audio device sits on - think of it as a PCI Bridge of sorts.
That's why 8086 1E20 shows up under the Cirrus 4206b when it does work. The intel controller has to start for the Cirrus to be detected. Look at my attachment Under Audio Devices, you see the nVidia and Cirrus controllers. Then under system devices, you see two 'High Definition Audio Controllers' - one of them is an nVidia HD Audio bus, the other is an Intel. The Intel one refuses to start in EFI installs.
Click to expand.Thanks, that clarifies a lot. Is the Cirrus device using a Cirrus driver or the Microsoft hdaudbus driver? Seems like the EFI driver problem could still be on the Intel side though.
I am inclined not to let Intel or Microsoft off the hook yet. If I had to place bets on blame it would be odds vendor issue 50% Apple (likely an EFI implementation problem) 25% Microsoft (likely a UAA driver problem) 20% Intel (likely a chipset driver problem) 5% Cirrus (unlikely but possible audio driver problem). Thanks, that clarifies a lot. Is the Cirrus device using a Cirrus driver or the Microsoft hdaudbus driver? Seems like the EFI driver problem could still be on the Intel side though. I am inclined not to let Intel or Microsoft off the hook yet.
If I had to place bets on blame it would be odds vendor issue 50% Apple (likely an EFI implementation problem) 25% Microsoft (likely a UAA driver problem) 20% Intel (likely a chipset driver problem) 5% Cirrus (unlikely but possible audio driver problem). Click to expand.Cirrus device is using a Cirrus driver. I suspect it would work fine in EFI mode, but since the HD Audio Bus can't be mounted, Windows doesn't even realize the Cirrus is there at all. I think everyone shares a bit in the blame - but I suspect the root of the problem comes down to Intel. Since the issue appears on multiple brand motherboards, the faulty code probably comes down to early versions of the base EFI firmware that Intel developed.
Xbib-u-dev Rev 3 Drivers For Mac Download
It appears it has been since fixed, but since Apple has not updated to EFI 2.x, the issue is probably there due to old code. But then one has to consider that the issue only manifests in Windows - Linux can mount the audio devices just fine. So there may be something wrong with Microsoft's method of mounting EFI devices. OR they're simply enforcing the 'rules' more strictly. I think the root cause lies with Intel, but the fix is something Apple would have to implement. Cirrus device is using a Cirrus driver.
I suspect it would work fine in EFI mode, but since the HD Audio Bus can't be mounted, Windows doesn't even realize the Cirrus is there at all. I think everyone shares a bit in the blame - but I suspect the root of the problem comes down to Intel. Since the issue appears on multiple brand motherboards, the faulty code probably comes down to early versions of the base EFI firmware that Intel developed. It appears it has been since fixed, but since Apple has not updated to EFI 2.x, the issue is probably there due to old code. But then one has to consider that the issue only manifests in Windows - Linux can mount the audio devices just fine. So there may be something wrong with Microsoft's method of mounting EFI devices. OR they're simply enforcing the 'rules' more strictly.
Xbib-u-dev Rev 3 Drivers For Mac Pro
I think the root cause lies with Intel, but the fix is something Apple would have to implement. If you can figure something out that'd be great. I too think that perhaps some kin of startup script would do the trick. But the problem is figuring out what to script - Yeah we are.
As mentioned before it works fine in BIOS mode but not in EFI mode. Presumably if our technique works in one mode, it should have worked in the other mode if there weren't any quirks. It may be an ivy bridge issue.
Xbib-u-dev Rev 3 Drivers For Mac Free
I wonder if 2012 cMBP owners can get the intel HD audio bus to work. And if so, I'd be very curious to see where the difference lies.