From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anssi Hannula Subject: Re: [PATCH] ALSA: hda - Fix the workaround for conflicting IEC958 controls Date: Tue, 12 Feb 2013 17:51:37 +0200 Message-ID: <511A6509.9010706@iki.fi> References: <1360363479-15678-1-git-send-email-anssi.hannula@iki.fi> <51177EEA.7080704@iki.fi> <38a2644a9142828043dab3b331c1c707@mail.onse.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-gw-out1.cc.tut.fi (mail-gw-out1.cc.tut.fi [130.230.160.32]) by alsa0.perex.cz (Postfix) with ESMTP id 2479626511C for ; Tue, 12 Feb 2013 16:51:40 +0100 (CET) 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 11.02.2013 13:28, Takashi Iwai kirjoitti: > At Mon, 11 Feb 2013 13:20:03 +0200, > Anssi Hannula wrote: >> >> On 11.02.2013 12:51, Takashi Iwai wrote: >>> At Sun, 10 Feb 2013 13:05:14 +0200, >>> Anssi Hannula wrote: >>>> >>>> 10.02.2013 12:38, Takashi Iwai kirjoitti: >>>>> At Sat, 9 Feb 2013 00:44:39 +0200, >>>>> Anssi Hannula wrote: >>>>>> >>>>>> Commit dcda5806165c155d90b9aa466a1602cf4726012b ("ALSA: hda - Add >>>>>> workaround for conflicting IEC958 controls") added a workaround >>>> for >>>>>> cards that have both an S/PDIF and an HDMI device, so that S/PDIF >>>> IEC958 >>>>>> controls will be moved to device=1 on such cards. >>>>>> >>>>>> However, the workaround did not take it into account that the >>>> S/PDIF and >>>>>> HDMI devices may be on different codecs of the same card. >>>> Currently this >>>>>> is always the case, and the workaround therefore fails to work. >>>>>> >>>>>> Fix the workaround to handle card-wide IEC958 conflicts. >>>>>> >>>>>> Reported-by: Stephan Raue >>>>>> Signed-off-by: Anssi Hannula >>>>>> --- >>>>>> >>>>>> Unfortunately this seems to cause a nasty issue with alsa-lib >>>> 1.0.26: >>>>>> $ amixer scontrols -c 0 >>>>>> ALSA lib simple_none.c:1551:(simple_add1) helem (MIXER,'IEC958 >>>> Playback Switch',0,1,0) appears twice or more >>>>>> amixer: Mixer hw:0 load error: Invalid argument >>>>>> >>>>>> The non-simple-mode "amixer controls -c 0" works fine, though. >>>>>> >>>>>> Not really sure what to do now then, do we revert the workaround >>>>>> completely and devise a different workaround/fix for this, or do >>>> you >>>>>> have some other good ideas? >>>>> >>>>> If the element isn't really dup'ed, it must be a bug in alsa-lib >>>> mixer >>>>> abstraction, so it should be fixed there. >>>> >>>> This is because the simple mixer interface only identifies controls >>>> by >>>> name+index: >>>> >>>> http://www.alsa-project.org/alsa-doc/alsa-lib/group___simple_mixer.html >>>> >>>> So controls that only differ by device (or subdevice?) are >>>> considered >>>> duplicated. I did look at the code but saw no straight-forward way >>>> to >>>> fix it, other than to introduce devices (and subdevices) to the >>>> simple >>>> mixer API (which is used by outside applications). >>> >>> OK, so it's a limitation of alsa-lib mixer simple abst >>> implementation. We need to live with that for now... >>> >>>> Anyway, wouldn't breaking "old" alsa-lib make this way of fixing it >>>> a >>>> no-go (the error is fatal and mixer creation fails completely)? >>> >>> No, it's a general rule in the kernel that we can't break the old >>> user-space. >> >> Isn't that a "yes" for my no-go? ;) > > I hate double negation :) > > >>>>> Could you add alsa-info.sh output of this board (at best before >>>> and >>>>> after your patch)? >>>> >>>> Here's one after patch (can't get one before patch right now, but I >>>> guess it isn't needed since the cause is very clear): >>>> >>>> http://www.alsa-project.org/db/?f=bb3fc8680b372c0475719d42d7fc8b2bb7bfb4eb >>>> (this one has alsa-lib hack applied which ignores the failure to add >>>> the >>>> control so that the mixer error is non-fatal) >>> >>> Thinking it again, maybe an ugly but working workaround is to shift >>> the SPDIF index to high enough not conflicting with HDMI, instead of >>> changing the ctl device. >>> >>> The quick patch below is to put the SPDIF stuff into index=16+. It >>> also fixes the issue of multiple codecs. >>> >>> Of course, this will require a similar fix in alsa-lib config. >>> Instead of changing dev to 1, just change index to 16. >> >> OK, patch looks fine to me. I'll test this later today or tomorrow and >> report >> back. > > Thanks. The patch below is the revised alsa-lib patch corresponding > to this fix. Seems to work fine :) >> Also, sorry for not catching this earlier. > > Oh no, thanks for updates! > > > thanks, > > Takashi -- Anssi Hannula