Hi,
there is a long-standing problem in HD-audio regarding IEC958 controls. When both an SPDIF and an HDMI are created on the same card (e.g. one from analog codec and one from graphics chip), the driver assigns the IEC958 controls just with new indices, 0, 1, 2...
The problem is that there is no way to connect between this index and the actual PCM device. Currently, alsa-lib HDA-Intel.conf has a fixed configuration: spdif -> IEC958 xxx index=0, PCM dev=1 hdmi,0 -> IEC958 xxx index=0, PCM dev=3 hdmi,1 -> IEC958 xxx index=1, PCM dev=7 hdmi,2 -> IEC958 xxx index=2, PCM dev=8 hdmi,3 -> IEC958 xxx index=3, PCM dev=9
So obviously spdif and the first hdmi conflict.
Basically this can be fixed by reassigning each IEC958 control with the same device number corresponding to the PCM device. That is, for SPDIF, assign a control element with device=1, for HDMI, device=3,7... However, this obviously breaks the old configuration unless user upgrades the alsa-lib configuration. Thus this is no-go.
Now here is a compromise: the IEC958 control for SPDIF is reassigned to device=1 *only* when SPDIF and HDMI coexist. Since the configuration is anyway broken as is now in such a case, it's no big deal to fix one side in an incompatible way. (The reason why SPDIF is re-assigned is that I guess majority of user require more HDMI than SPDIF in such a configuration.)
In addition, we need a fix in alsa-lib. Also not for breaking the compatibility with older kernel, we need some fallback check. I did a quick hack to alsa-lib conf code and added "skip_rest" option to the hook element, so that only the first matching element is taken.
Long story short, I cooked up three patches. One patch is for kernel, to add the workaround above, and the two are for alsa-lib, one clean up and one to introduce the skip_rest option (and application to HDA-Intel.conf).
My plan is to merge this to 3.8 tree, so it's no urgent issue. But it's of course always good to fix something.
thanks,
Takashi