snd_hda(4) pin routing issues

[Alexey Dokuchaev]

On Sat, Jul 31, 2010 at 11:32:18PM +0700, Alexey Dokuchaev wrote:
> Hello there again, [ let's try it one more time ]
> 
> I'm trying to get sound working on NEC Versa S950 laptop of mine, which
> is recognized by snd_hda(4), but unfortunately, playback does not work
> out of the box: [...]

Still no sound for me after upgrading to 8-stable.  I've booted Ubuntu
livecd and (surprise!) the sounds works, both playback and recording.
I've downloaded latest alsa-driver-1.0.24 sources, and apparently, they
do quite some magic in alsa-kernel/pci/hda/patch_sigmatel.c:

1) my sound card (8384:7690) is reported as STAC9220 on FreeBSD, but
ALSA code lists it as STAC9200; -- can that be a problem?

2) my codec seems reference one, and ALSA applies the following pin
configuration (in addition to other things):

static unsigned int ref9200_pin_configs[8] = {
	0x01c47010, 0x01447010, 0x0221401f, 0x01114010,
	0x02a19020, 0x01a19021, 0x90100140, 0x01813122,
};

These values vaguely match what I see from our snd_hda(4), but I am
not sure how to properly apply them via device hints.  Before I dig
deeply into the guts, maybe someone knowledgeable can provide my with some
guidance while I'm still on the "river bank"?

> Am I missing something?  Comparing verbose dmesg outputs (relevant lines
> attached for both cases) does not immediately reveal why recording gets
> broken with nid13 sequence number reassigned.  Attached files can be
> also found here in case our mailman drops attachments:
> 
> 	http://193.124.210.26/dmesg.verbose.default
> 	http://193.124.210.26/dmesg.verbose.hinted

In addition to the above, contents of Linux' /proc/asound/card0/ files
is available here:

	http://193.124.210.26/alsa-hda-dump

./danfe