[alsa-devel] [RFC] Fix for conflict of HDMI and SPDIF IEC958 controls

[Takashi Iwai]

At Mon, 15 Oct 2012 13:11:00 +0200,
Jaroslav Kysela wrote:
> 
> Date 15.10.2012 12:31, Takashi Iwai wrote:
> > At Mon, 15 Oct 2012 12:21:18 +0200,
> > Jaroslav Kysela wrote:
> >>
> >> Date 12.10.2012 17:18, Takashi Iwai wrote:
> >>> 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.
> >>
> >> What about to introduce more cleaner solution - export this information
> >> using TLV to user space, so alsa-lib can enumerate (distinguish) the
> >> spdif and hdmi devices properly.
> > 
> > Yes, this is the next step I've planned.  The additional information
> > doesn't conflict with this fix.
> > 
> > The point of this fix is to keep / fix the things working as much as
> > possible even without changing user-space.  If a user-space upgrade is
> > mandatory, it can be regarded as an obvious regression.
> > 
> > In short, my patch is:
> > - A quick fix
> > - Doesn't break the cases without SPDIF/HDMI conflict
> > - Fixes HDMI for the conflicting case even without changing user-space
> > - Would break the SPDIF output (only when SPDIF/HDMI conflicts)
> >   without config update
> 
> I understand, but because the config update mostly depends on the whole
> alsa-lib package update, then I believe, the proper fix may be
> implemented now rather than introducing a config hack option. But the
> step-by-step improvement is ok to me, too.

Yep, a "proper" fix would be to improve the alsa-lib config.
I wouldn't take such a too hackish option, too, if no big rewrite is
needed...


Takashi