From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaroslav Kysela Subject: Re: [RFC] Fix for conflict of HDMI and SPDIF IEC958 controls Date: Mon, 15 Oct 2012 13:11:00 +0200 Message-ID: <507BEF44.1040607@perex.cz> References: <507BE39E.5070306@perex.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail1.perex.cz (mail1.perex.cz [77.48.224.245]) by alsa0.perex.cz (Postfix) with ESMTP id 37308264FFF for ; Mon, 15 Oct 2012 13:11:01 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org 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. Jaroslav -- Jaroslav Kysela Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.