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@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