Hi Jason, Thanks for your help. Ultimately, I think there is more too it than that. These are the latest comments from our audio developer, David Henningsson, about the issue:
I hope I can remember the situation correctly. This is essentially a longer version of what I wrote before. First, the unusual thing about these particular devices is that it seems the integrated monitor is internally connected over HDMI. This means that, seen from the driver's perspective, there are two HDMI outputs. This has been less tested than one HDMI output (on Haswell), but there are chances this works better in the 3.11 kernel - I'm not sure. Second, the internal monitor does not have any audio capabilities (the internal analog audio is connected to the ALC668 codec, not the HDMI monitor), but still, the internal monitor advertises audio capabilities (as seen in ELD info). This is something we could talk to the OSV about, to see if they could change this: the monitor should not advertise being able to play back audio, if it can't. Third, (maybe meant as a workaround to the just mentioned issue about ELD info?) some audio codec pins are marked as "not connected" by BIOS. However, this workaround is not working, at least not on Linux. This is where I've been trying to get clear answers from Intel, but still have not received any, even though we have had long discussions and even phone calls about it. In short, there seem to be uncertainty on the Intel side how their hardware actually works: First, how the audio codec pins are actually connected to the available physical outputs, pipes or transcoders. Second, if disabling pins in BIOS should be regarded as an error on the Haswell platform or not. Some Intel developers think so, but we need a clear statement from Intel that this is the case before we can tell the OEM they should change BIOS. I hope this clarifies the status of this issue. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1183125 Title: Haswell: Ensuring HDA codec pins refer to physical outputs Status in intel: New Status in System76: In Progress Status in “linux” package in Ubuntu: Incomplete Status in “linux” source package in Quantal: In Progress Status in “linux” source package in Raring: In Progress Bug description: From David's email: http://mailman.alsa-project.org/pipermail/alsa- devel/2013-May/062105.html The HDA driver assumes that a codec pin widget node always refers to the same physical output. With Haswell, it seems like this is not guaranteed to be true. I would like to see this fixed on the graphics side. If not, I don't know how to work around it on the audio side. The problems that occur on the audio side are: 1) Some BIOSes set default pin config. E g, if the machine has a single HDMI out, it can set two of the codec pins to "not connected" and let the third remain "jack". As a result, the HDA driver will ignore the two codec pins and only enable the third. As such, HDMI audio will not work correctly, unless it's the third codec pin that is connected to the physical output. 2) Saving and restoring mutes, volumes etc is done on a per-pin basis. E g, imagine that a user has a dual monitor setup and always wants audio output from the left side monitor, and keep the right side monitor silent. If it is not reliable which codec pin refers to which physical output, one day suddenly the sound might come out on the right side monitor instead. To manage notifications about this bug go to: https://bugs.launchpad.net/intel/+bug/1183125/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
