From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Major reworks on patch_via.c (TESTERS WANTED) Date: Mon, 04 Jul 2011 14:55:31 +0200 Message-ID: References: Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 8667E24527 for ; Mon, 4 Jul 2011 14:55:33 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: alex dot baldacchino dot alsasub at gmail dot com Cc: Raymond Yau , ALSA Development Mailing List , haraldwelte@viatech.com, lydiawang List-Id: alsa-devel@alsa-project.org At Sat, 2 Jul 2011 18:00:27 +0200, alex dot baldacchino dot alsasub at gmail dot com wrote: > > 2011/6/22 Takashi Iwai : > > At Mon, 20 Jun 2011 17:06:51 +0200, > > Takashi Iwai wrote: > >> > >> Hi, > >> > >> as there have many problems reported for VIA codecs, I started looking > >> at the driver code, and decided to rework on it. > >> [...] > > I've installed and tested (from tarballs) both snapshot > alsa-driver-20110630 and latest version (alsa-driver-snapshot.tar.gz) > - up to commit e5e14681404ec27a422d635284bf564dabde3f81 by Lydia Wang, > I think. > > I've found problems with both. That's a quite huge change in the > implementation from older code, so I need to study it more in depth to > understand it better... At the moment I can only describe the problems > and give my first impressions on them. > > First of all, I can't get sound from the front playback (rear > line-out). ... > If I remember well what Lydia Wang told me in another thread, 0x21 is > connected to a dac (should be the front dac), even if the connection > isn't visible through the driver. Without that verb, if I set 'stereo > mixer' as first input source and try to record some playback, I get > only noise, with such initialization I can record an ongoing playback > (eventually mixed with other sound, e.g. from my mic). Such a result > tells me nid 0x8 (front dac, the only involved in my recording test) > should work properly even if no sound gets to front line-out pin > (0x24). A side effect of this, however, is that, depending on volumes > settings, whatever widget getting input also by 0x21 (and if such > connection isn't muted), will get sound by 0x8 while playing - e.g. I > can hear, at a lower volume, a playback setup for the front dac from > my headset even when Independent HP is set to ON; on the other hand, > lowering volumes attenuates such, but playback may become unrecordable > (due to volume being too low). These should be fixed now by Lydia's patch. I updated sound git tree and snapshot tarball now. Please check it later. > One notably thing is that the new (for codec VT1718S family) Master > control misses a few slaves, mainly: > > - as expectable, there's neither a "Side Playback Volume" nor a "Side > Playback Switch", since there's no grey jack (to support 7.1 systems, > my motherboard line-in (0x2a) should be re-tasked as output and get > input from the now available 0xc, which is no more used by headphones) > > - more noticeably, there's no "Headphone Playback Volume" control. > There was one in old implementation, explicitly created by > vt1718S_auto_create_hp_ctls(); within that function it was easy to > bind that control to the actual hp_nid (replacing any occurrence of > 0xc with spec->multiout.hp_nid in all relevant functions, the switch > from 0xc to 0xb was complete), given that the only reason to test > usability of dac at 0xb for headphone was, initially, to check whether > 0xc could be freed for use with 0x2a as side (and ensure, or confirm, > this codec family can handle as much as 10 channels - but to confirm > it definitely an attempt to retask 0x2a should be made). > > > Moreover, looking at codec informations, now control "Independent HP" > is attached to hp pin, altogether with control "Headphone Playback > Switch". This should be somehow more consistent with those codecs not > using an intermidiate selector to choose the nid to get sound from > (perhaps the majority), so that such control always sticks in same (or > corresponding) places. However, this way there is more 'distance' > between such control and the 'real' nid it works on. Hm, I'll check this with your alsa-info.sh output. > A final (minor) question/consideration on the code. I've noticed now > .put helpers validate data gathered from userspace (typically, passed > through ucontrol parameter), which is a good choice to protect against > some bug external to the driver; however, if I'm not mistaken, > via_mux_enum_put (and corresponding _get) could still be missing > something: since any data in ucontrol->id is passed as is to > snd_ctl_get_ioffidx, is there any chance that the result could be an > invalid index? No, such an invalid id will be filtered out in the upper layer. thanks, Takashi