[alsa-devel] Major reworks on patch_via.c (TESTERS WANTED)

[Takashi Iwai]

At Sat, 2 Jul 2011 18:00:27 +0200,
alex dot baldacchino dot alsasub at gmail dot com wrote:
> 
> 2011/6/22 Takashi Iwai <tiwai at suse.de>:
> > 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