Thread: [Alsa-user] nForce 430 / ASUS M2NPV-VM snd_hda_intel (surround) sound problems
Brought to you by:
perex
From: Trevor B. <tg...@sf...> - 2007-02-19 18:33:31
|
As posted to linuxquestions.org. They redirected me here... --- Please, for the sweet love of Zombie Jeebus, help me. I have two machines using an ASUS M2NPV-VM motherboard, both running Slackware Linux 11.0. One machine is my home file+web server and MythTV backend (with 2.0 speakers). The other machine is my HTPC frontend and dual-boots to XP and Linux. That machine now has 5.1 speakers that work great in It's a great motherboard and Linux works well on both, except for the sound. I can compile snd_hda_intel and it *kind of* works. If you touch the alsamixer volume, occasionally the sound dies. Or sometimes the sound doesn't come up at boot. Or, sometimes, if you mute and unmute the sound in alsamixer on the 5.1 speakers, 5 of the 6 speakers start working. Or sometimes if you rerun alsaconf and alsamixer it starts working again, but often it doesn't. Mostly, sound doesn't work and it's frustrating. I've read around for various solutions, and decided to attempt to upgrade my alsa-driver to 1.0.13. However when I attempt to modprobe snd_hda_intel, I get the following error: FATAL: Error inserting snd_hda_intel (/lib/modules/2.6.18.2/kernel/sound/pci/hda/snd-hda-intel.ko): Unknown symbol in module, or unknown parameter (see dmesg) If I run dmesg, I get get errors of the type: snd_hda_intel: Unknown symbol snd_verbose_printk snd_hda_intel: Unknown symbol snd_verbose_printd snd_hda_intel: Unknown symbol snd_hidden_kzalloc snd_hda_intel: Unknown symbol snd_hidden_kcalloc snd_hda_intel: Unknown symbol snd_hidden_kfree using depmod on snd_hda_intel actually appears to delete the snd_hda_intel drivers! I've seen other posts mention "Unknown symbol", only to have the original poster come back and say they've "fixed the problem" with no further data. I can get things somewhat back to normal by recompiling my kernel snd_hda_intel drivers using make modules_install from my kernel directory. This is driving me nuts. Getting sound working on my HTPC and MythBackend is the one thing holding me back from using my mythfrontend properly. Does anyone have any suggestions, or links to threads with concrete solutions? I appreciate the help. Trevor Bradley Surrey, B.C., Canada |
From: Oliver L. <oli...@gm...> - 2007-02-19 18:51:29
|
Trevor Bradley wrote: > As posted to linuxquestions.org. They redirected me here... > > --- > > Please, for the sweet love of Zombie Jeebus, help me. > > I have two machines using an ASUS M2NPV-VM motherboard, both running > Slackware Linux 11.0. One machine is my home file+web server and MythTV > backend (with 2.0 speakers). The other machine is my HTPC frontend and > dual-boots to XP and Linux. That machine now has 5.1 speakers that work > great in > > It's a great motherboard and Linux works well on both, except for the > sound. I can compile snd_hda_intel and it *kind of* works. If you touch > the alsamixer volume, occasionally the sound dies. Or sometimes the > sound doesn't come up at boot. Or, sometimes, if you mute and unmute the > sound in alsamixer on the 5.1 speakers, 5 of the 6 speakers start > working. Or sometimes if you rerun alsaconf and alsamixer it starts > working again, but often it doesn't. Mostly, sound doesn't work and it's > frustrating. > > I've read around for various solutions, and decided to attempt to > upgrade my alsa-driver to 1.0.13. However when I attempt to modprobe > snd_hda_intel, I get the following error: > > FATAL: Error inserting snd_hda_intel > (/lib/modules/2.6.18.2/kernel/sound/pci/hda/snd-hda-intel.ko): Unknown > symbol in module, or unknown parameter (see dmesg) > > If I run dmesg, I get get errors of the type: > > snd_hda_intel: Unknown symbol snd_verbose_printk > snd_hda_intel: Unknown symbol snd_verbose_printd > snd_hda_intel: Unknown symbol snd_hidden_kzalloc > snd_hda_intel: Unknown symbol snd_hidden_kcalloc > snd_hda_intel: Unknown symbol snd_hidden_kfree > > using depmod on snd_hda_intel actually appears to delete the > snd_hda_intel drivers! > > I've seen other posts mention "Unknown symbol", only to have the > original poster come back and say they've "fixed the problem" with no > further data. I can get things somewhat back to normal by recompiling my > kernel snd_hda_intel drivers using make modules_install from my kernel > directory. > > This is driving me nuts. Getting sound working on my HTPC and > MythBackend is the one thing holding me back from using my mythfrontend > properly. > > Does anyone have any suggestions, or links to threads with concrete > solutions? I appreciate the help. > > Trevor Bradley > Surrey, B.C., Canada I use Gentoo rather than Slackware, so that's where my experience lies. But whenever I've seen the endless undefined symbol errors it's been when working with both externally compiled alsa-driver modules and those distributed with the kernel. On Gentoo then the alsa-driver ones get installed to a different path in /lib/modules/, maybe search there and check you don't have two instances of the same modules? That's just what the issue has been whenever I've seen or heard about it, it could be something different. Out of interest, what chipset does your card have? I've been having endless problems trying to get 5.1 to work at all on my Asus (A8N-VM CSM, AD1986A chipset) using the hda-intel driver. Cheers, -ol |
From: Trevor B. <tg...@sf...> - 2007-02-19 19:09:22
|
Oliver Lupton wrote: > Trevor Bradley wrote: >> As posted to linuxquestions.org. They redirected me here... >> >> --- >> >> Please, for the sweet love of Zombie Jeebus, help me. >> >> I have two machines using an ASUS M2NPV-VM motherboard, both running >> Slackware Linux 11.0. One machine is my home file+web server and >> MythTV backend (with 2.0 speakers). The other machine is my HTPC >> frontend and dual-boots to XP and Linux. That machine now has 5.1 >> speakers that work great in >> >> It's a great motherboard and Linux works well on both, except for the >> sound. I can compile snd_hda_intel and it *kind of* works. If you >> touch the alsamixer volume, occasionally the sound dies. Or sometimes >> the sound doesn't come up at boot. Or, sometimes, if you mute and >> unmute the sound in alsamixer on the 5.1 speakers, 5 of the 6 >> speakers start working. Or sometimes if you rerun alsaconf and >> alsamixer it starts working again, but often it doesn't. Mostly, >> sound doesn't work and it's frustrating. >> >> I've read around for various solutions, and decided to attempt to >> upgrade my alsa-driver to 1.0.13. However when I attempt to modprobe >> snd_hda_intel, I get the following error: >> >> FATAL: Error inserting snd_hda_intel >> (/lib/modules/2.6.18.2/kernel/sound/pci/hda/snd-hda-intel.ko): >> Unknown symbol in module, or unknown parameter (see dmesg) >> >> If I run dmesg, I get get errors of the type: >> >> snd_hda_intel: Unknown symbol snd_verbose_printk >> snd_hda_intel: Unknown symbol snd_verbose_printd >> snd_hda_intel: Unknown symbol snd_hidden_kzalloc >> snd_hda_intel: Unknown symbol snd_hidden_kcalloc >> snd_hda_intel: Unknown symbol snd_hidden_kfree >> >> using depmod on snd_hda_intel actually appears to delete the >> snd_hda_intel drivers! >> >> I've seen other posts mention "Unknown symbol", only to have the >> original poster come back and say they've "fixed the problem" with no >> further data. I can get things somewhat back to normal by recompiling >> my kernel snd_hda_intel drivers using make modules_install from my >> kernel directory. >> >> This is driving me nuts. Getting sound working on my HTPC and >> MythBackend is the one thing holding me back from using my >> mythfrontend properly. >> >> Does anyone have any suggestions, or links to threads with concrete >> solutions? I appreciate the help. >> >> Trevor Bradley >> Surrey, B.C., Canada > > I use Gentoo rather than Slackware, so that's where my experience > lies. But whenever I've seen the endless undefined symbol errors it's > been when working with both externally compiled alsa-driver modules > and those distributed with the kernel. On Gentoo then the alsa-driver > ones get installed to a different path in /lib/modules/, maybe search > there and check you don't have two instances of the same modules? > That's just what the issue has been whenever I've seen or heard about > it, it could be something different. > > Out of interest, what chipset does your card have? I've been having > endless problems trying to get 5.1 to work at all on my Asus (A8N-VM > CSM, AD1986A chipset) using the hda-intel driver. > > Cheers, > -ol Yep, it appears this motherboard also as an AD1986A chipset. It'll be the starting point for my next search. I can't check too well on this remotely unfortunately. I'll have to try when I get home. I don't see any duplicate drivers though. Trevor Bradley Surrey, B.C., Canada |
From: Trevor B. <tg...@sf...> - 2007-02-22 22:35:07
|
For reference, I've fixed this problem. Be sure not to just do an rmmod of snd_hda_codec, but *every* snd module. Do an lsmod and rmmod everything that looks like snd*. I was trying to reload snd_hda_codec while leaving other alsa 1.0.11 drivers loaded. That should have been obvious, but it wasn't. No clue if 1.0.14rc2 works at all (I'm sshing to home to fix it), but at least I have updated drivers. Thanks for the advice Oliver. Eventually I got it. :) Trevor Bradley Oliver Lupton wrote: > Trevor Bradley wrote: >> As posted to linuxquestions.org. They redirected me here... >> >> --- >> >> Please, for the sweet love of Zombie Jeebus, help me. >> >> I have two machines using an ASUS M2NPV-VM motherboard, both running >> Slackware Linux 11.0. One machine is my home file+web server and >> MythTV backend (with 2.0 speakers). The other machine is my HTPC >> frontend and dual-boots to XP and Linux. That machine now has 5.1 >> speakers that work great in >> >> It's a great motherboard and Linux works well on both, except for the >> sound. I can compile snd_hda_intel and it *kind of* works. If you >> touch the alsamixer volume, occasionally the sound dies. Or sometimes >> the sound doesn't come up at boot. Or, sometimes, if you mute and >> unmute the sound in alsamixer on the 5.1 speakers, 5 of the 6 >> speakers start working. Or sometimes if you rerun alsaconf and >> alsamixer it starts working again, but often it doesn't. Mostly, >> sound doesn't work and it's frustrating. >> >> I've read around for various solutions, and decided to attempt to >> upgrade my alsa-driver to 1.0.13. However when I attempt to modprobe >> snd_hda_intel, I get the following error: >> >> FATAL: Error inserting snd_hda_intel >> (/lib/modules/2.6.18.2/kernel/sound/pci/hda/snd-hda-intel.ko): >> Unknown symbol in module, or unknown parameter (see dmesg) >> >> If I run dmesg, I get get errors of the type: >> >> snd_hda_intel: Unknown symbol snd_verbose_printk >> snd_hda_intel: Unknown symbol snd_verbose_printd >> snd_hda_intel: Unknown symbol snd_hidden_kzalloc >> snd_hda_intel: Unknown symbol snd_hidden_kcalloc >> snd_hda_intel: Unknown symbol snd_hidden_kfree >> >> using depmod on snd_hda_intel actually appears to delete the >> snd_hda_intel drivers! >> >> I've seen other posts mention "Unknown symbol", only to have the >> original poster come back and say they've "fixed the problem" with no >> further data. I can get things somewhat back to normal by recompiling >> my kernel snd_hda_intel drivers using make modules_install from my >> kernel directory. >> >> This is driving me nuts. Getting sound working on my HTPC and >> MythBackend is the one thing holding me back from using my >> mythfrontend properly. >> >> Does anyone have any suggestions, or links to threads with concrete >> solutions? I appreciate the help. >> >> Trevor Bradley >> Surrey, B.C., Canada > > I use Gentoo rather than Slackware, so that's where my experience > lies. But whenever I've seen the endless undefined symbol errors it's > been when working with both externally compiled alsa-driver modules > and those distributed with the kernel. On Gentoo then the alsa-driver > ones get installed to a different path in /lib/modules/, maybe search > there and check you don't have two instances of the same modules? > That's just what the issue has been whenever I've seen or heard about > it, it could be something different. > > Out of interest, what chipset does your card have? I've been having > endless problems trying to get 5.1 to work at all on my Asus (A8N-VM > CSM, AD1986A chipset) using the hda-intel driver. > > Cheers, > -ol -- Trevor Bradley Computer Systems Administrator Systems and Technical Services (STS) Learning and Instructional Development Center (LIDC) Simon Fraser University, Surrey, B.C. Canada |
From: Prakash P. <pr...@pu...> - 2007-04-13 15:24:23
|
Am Donnerstag 22 Februar 2007 schrieb Trevor Bradley: > For reference, I've fixed this problem. Be sure not to just do an rmmod > of snd_hda_codec, but *every* snd module. Do an lsmod and rmmod > everything that looks like snd*. I was trying to reload snd_hda_codec > while leaving other alsa 1.0.11 drivers loaded. > > That should have been obvious, but it wasn't. > > No clue if 1.0.14rc2 works at all (I'm sshing to home to fix it), but at > least I have updated drivers. > > Thanks for the advice Oliver. Eventually I got it. :) Could you tell me how you got it working? I have the same mobo and I only managed to get stereo out of it. I am currently using kernel 2.6.21-rc6. I am testing with speaker-test -Dplug:surround51 -c 6 I have unmuted and set vol to high/max for pcm, front, surround, center and lfe. I have set channel to 6ch. Everything else is muted. :-( -- (°= =°) //\ Prakash Punnoor /\\ V_/ \_V |
From: Trevor B. <tg...@sf...> - 2007-04-13 15:51:03
|
I *didn't* get it working. I eventually got stereo sound working by eliminating all references to 5.1 sound (try eliminating your .asoundrc file if you've already created one). If your drivers are giving you a hassle after recompiling, try rebooting. There are a lot of dependent drivers and rebooting will be sure to unload them all. I was able to easily give up when I realized my 5.1 speakers had a button to push 2.0 sound to all 5 speakers. I'm still eager to hear if anyone has a working 5.1 solution for this motherboard. Trevor Bradley Surrey, B.C. Canada Prakash Punnoor wrote: > Am Donnerstag 22 Februar 2007 schrieb Trevor Bradley: > >> For reference, I've fixed this problem. Be sure not to just do an rmmod >> of snd_hda_codec, but *every* snd module. Do an lsmod and rmmod >> everything that looks like snd*. I was trying to reload snd_hda_codec >> while leaving other alsa 1.0.11 drivers loaded. >> >> That should have been obvious, but it wasn't. >> >> No clue if 1.0.14rc2 works at all (I'm sshing to home to fix it), but at >> least I have updated drivers. >> >> Thanks for the advice Oliver. Eventually I got it. :) >> > > > Could you tell me how you got it working? I have the same mobo and I only > managed to get stereo out of it. I am currently using kernel 2.6.21-rc6. I am > testing with > > speaker-test -Dplug:surround51 -c 6 > > I have unmuted and set vol to high/max for pcm, front, surround, center and > lfe. I have set channel to 6ch. Everything else is muted. > > :-( > > |
From: Prakash P. <pr...@pu...> - 2007-04-14 09:25:20
|
Am Freitag 13 April 2007 schrieb Trevor Bradley: > I *didn't* get it working. I eventually got stereo sound working by > eliminating all references to 5.1 sound (try eliminating your .asoundrc > file if you've already created one). [..] > Prakash Punnoor wrote: > > Am Donnerstag 22 Februar 2007 schrieb Trevor Bradley: > >> For reference, I've fixed this problem. Be sure not to just do an rmm= od > >> of snd_hda_codec, but *every* snd module. Do an lsmod and rmmod > >> everything that looks like snd*. I was trying to reload snd_hda_codec > >> while leaving other alsa 1.0.11 drivers loaded. > >> > >> That should have been obvious, but it wasn't. > >> > >> No clue if 1.0.14rc2 works at all (I'm sshing to home to fix it), but = at > >> least I have updated drivers. > >> > >> Thanks for the advice Oliver. Eventually I got it. :) > > > > Could you tell me how you got it working? I have the same mobo and I on= ly > > managed to get stereo out of it. I am currently using kernel 2.6.21-rc6. > > I am testing with > > > > speaker-test -Dplug:surround51 -c 6 > > > > I have unmuted and set vol to high/max for pcm, front, surround, center > > and lfe. I have set channel to 6ch. Everything else is muted. > > > > :-( Hah! I managed it!!! Just tested with speaker-test, so far. I hacked the=20 driver a bit: In patch_analog.c in static int patch_ad1986a(struct hda_codec *codec) case AD1986A_3STACK: spec->num_mixers =3D 2; spec->mixers[1] =3D ad1986a_3st_mixers; //spec->num_init_verbs =3D 3; //spec->init_verbs[1] =3D ad1986a_3st_init_verbs; //spec->init_verbs[2] =3D ad1986a_ch2_init; spec->channel_mode =3D ad1986a_modes; spec->num_channel_mode =3D ARRAY_SIZE(ad1986a_modes); spec->need_dac_fix =3D 0;//1; spec->multiout.max_channels =3D 6;//2; spec->multiout.num_dacs =3D 3;//1; break; I don't yet know whether it is completely correct what I did and what is th= e=20 minimal change needed. Perhaps some of the changes will lead to regressions, I need to check furth= er.=20 I think setting max channels and num_dacs has nor meaning, as probably the = get=20 overwritten on ch set, right? dac_fix probably changes the way num_dacs are= =20 assigned to? So my guess is that probably setting ad1986a_3st_init_verbs is wrong for my= =20 mobo.=20 {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, What do those magic number 0x1 and 0x2 mean here? I looked into hda specs a= nd=20 ad1986a specs. 0xf is mic selector and 0x10 is line selector. Does is selec= t=20 which physical output is chosen? I will test later whether leaking dac_fix as 1 and ust taking out=20 ad1986a_3st_init_verbs will be enough. Cheers, =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Prakash P. <pr...@pu...> - 2007-04-14 12:14:19
|
Am Samstag 14 April 2007 schrieb Prakash Punnoor: > Hah! I managed it!!! Just tested with speaker-test, so far. I hacked the > driver a bit: > > In patch_analog.c in static int patch_ad1986a(struct hda_codec *codec) > > case AD1986A_3STACK: > spec->num_mixers =3D 2; > spec->mixers[1] =3D ad1986a_3st_mixers; > //spec->num_init_verbs =3D 3; > //spec->init_verbs[1] =3D ad1986a_3st_init_verbs; > //spec->init_verbs[2] =3D ad1986a_ch2_init; > spec->channel_mode =3D ad1986a_modes; > spec->num_channel_mode =3D ARRAY_SIZE(ad1986a_modes); > spec->need_dac_fix =3D 0;//1; > spec->multiout.max_channels =3D 6;//2; > spec->multiout.num_dacs =3D 3;//1; > break; > > I don't yet know whether it is completely correct what I did and what is > the minimal change needed. > > Perhaps some of the changes will lead to regressions, I need to check > further. > > I think setting max channels and num_dacs has nor meaning, as probably the > get overwritten on ch set, right? dac_fix probably changes the way num_da= cs > are assigned to? > > So my guess is that probably setting ad1986a_3st_init_verbs is wrong for = my > mobo. > > {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, > {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, > > What do those magic number 0x1 and 0x2 mean here? I looked into hda specs > and ad1986a specs. 0xf is mic selector and 0x10 is line selector. Does is > select which physical output is chosen? > > I will test later whether leaking dac_fix as 1 and ust taking out > ad1986a_3st_init_verbs will be enough. > > Cheers, OK, I was right. Taking out ad1986a_3st_init_verbs is enough for making it= =20 work: case AD1986A_3STACK: spec->num_mixers =3D 2; spec->mixers[1] =3D ad1986a_3st_mixers; spec->num_init_verbs =3D 1;//2; //spec->init_verbs[1] =3D ad1986a_3st_init_verbs; spec->init_verbs[2] =3D ad1986a_ch2_init; spec->channel_mode =3D ad1986a_modes; spec->num_channel_mode =3D ARRAY_SIZE(ad1986a_modes); spec->need_dac_fix =3D 1; spec->multiout.max_channels =3D 2; spec->multiout.num_dacs =3D 1; break; There is still one bug left for me: If I change ch setting, I need to adjus= t=20 vol for sur, cl/lfe again, otherwise they stay mute. Bug of driver or=20 alsamixer? Would be nice if we got a real fix for kernel 2.6.21. :-) Cheers, =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Oliver L. <oli...@gm...> - 2007-04-14 12:55:47
|
Prakash Punnoor wrote: > OK, I was right. Taking out ad1986a_3st_init_verbs is enough for making it > work: > > case AD1986A_3STACK: > spec->num_mixers = 2; > spec->mixers[1] = ad1986a_3st_mixers; > spec->num_init_verbs = 1;//2; > //spec->init_verbs[1] = ad1986a_3st_init_verbs; > spec->init_verbs[2] = ad1986a_ch2_init; > spec->channel_mode = ad1986a_modes; > spec->num_channel_mode = ARRAY_SIZE(ad1986a_modes); > spec->need_dac_fix = 1; > spec->multiout.max_channels = 2; > spec->multiout.num_dacs = 1; > break; > > There is still one bug left for me: If I change ch setting, I need to adjust > vol for sur, cl/lfe again, otherwise they stay mute. Bug of driver or > alsamixer? > > Would be nice if we got a real fix for kernel 2.6.21. :-) > > Cheers, On my A8N-VM then it's working with *init_verbs* commented, max_channels set to 6 and num_dacs set to 3. I haven't tried it, but if you're changing num_init_verbs to 1 then it looks like spec->init_verbs[2] = ad1986a_ch2_init; should have spec->init_verbs[1] instead? -ol |
From: Prakash P. <pr...@pu...> - 2007-04-14 14:45:13
|
Am Samstag 14 April 2007 schrieb Oliver Lupton: > Prakash Punnoor wrote: > > OK, I was right. Taking out ad1986a_3st_init_verbs is enough for making > > it work: > > > > case AD1986A_3STACK: > > spec->num_mixers =3D 2; > > spec->mixers[1] =3D ad1986a_3st_mixers; > > spec->num_init_verbs =3D 1;//2; > > //spec->init_verbs[1] =3D ad1986a_3st_init_verbs; > > spec->init_verbs[2] =3D ad1986a_ch2_init; > > spec->channel_mode =3D ad1986a_modes; > > spec->num_channel_mode =3D ARRAY_SIZE(ad1986a_modes); > > spec->need_dac_fix =3D 1; > > spec->multiout.max_channels =3D 2; > > spec->multiout.num_dacs =3D 1; > > break; > > > > There is still one bug left for me: If I change ch setting, I need to > > adjust vol for sur, cl/lfe again, otherwise they stay mute. Bug of driv= er > > or alsamixer? > > > > Would be nice if we got a real fix for kernel 2.6.21. :-) > > > > Cheers, > > On my A8N-VM then it's working with *init_verbs* commented, max_channels > set to 6 and num_dacs set to 3. > I haven't tried it, but if you're changing num_init_verbs to 1 then it > looks like spec->init_verbs[2] =3D ad1986a_ch2_init; should have > spec->init_verbs[1] instead? Oops, yes, of course copy & paste error. =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Oliver L. <oli...@gm...> - 2007-04-16 09:30:50
Attachments:
alsapatch.patch
|
Oliver Lupton wrote: > On my A8N-VM then it's working with *init_verbs* commented, max_channels > set to 6 and num_dacs set to 3. > I haven't tried it, but if you're changing num_init_verbs to 1 then it > looks like spec->init_verbs[2] = ad1986a_ch2_init; should have > spec->init_verbs[1] instead? > > -ol Just a couple of links. Bugreport which could probably be solved if one of these changes was applied to the main tree: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2478 I don't pretend to understand exactly what this change does, but the attached patch does work and allow 5.1 output on an A8N-VM CSM. -ol |
From: Dominique D. <dom...@fr...> - 2007-04-14 16:05:50
|
Prakash Punnoor <pr...@pu...> writes: > So my guess is that probably setting ad1986a_3st_init_verbs is wrong > for my mobo. > > {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, > {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, > > What do those magic number 0x1 and 0x2 mean here? I looked into hda > specs and ad1986a specs. 0xf is mic selector and 0x10 is line > selector. Does is select which physical output is chosen? As far as I have understood the spec, 0x2 means that NID 0xf widget's input is connected to the third widget listed in NID 0xf widget's connection list. It's like a pointer into the connection list. So you need widget's 0x0f connection list to know the actual widget connected its input. Likewise for 0x1. HTH |
From: Takashi I. <ti...@su...> - 2007-04-16 09:14:52
|
At Sat, 14 Apr 2007 11:24:49 +0200, Prakash Punnoor wrote: > > Am Freitag 13 April 2007 schrieb Trevor Bradley: > > I *didn't* get it working. I eventually got stereo sound working by > > eliminating all references to 5.1 sound (try eliminating your .asoundrc > > file if you've already created one). > > [..] > > Prakash Punnoor wrote: > > > Am Donnerstag 22 Februar 2007 schrieb Trevor Bradley: > > >> For reference, I've fixed this problem. Be sure not to just do an rmmod > > >> of snd_hda_codec, but *every* snd module. Do an lsmod and rmmod > > >> everything that looks like snd*. I was trying to reload snd_hda_codec > > >> while leaving other alsa 1.0.11 drivers loaded. > > >> > > >> That should have been obvious, but it wasn't. > > >> > > >> No clue if 1.0.14rc2 works at all (I'm sshing to home to fix it), but at > > >> least I have updated drivers. > > >> > > >> Thanks for the advice Oliver. Eventually I got it. :) > > > > > > Could you tell me how you got it working? I have the same mobo and I only > > > managed to get stereo out of it. I am currently using kernel 2.6.21-rc6. > > > I am testing with > > > > > > speaker-test -Dplug:surround51 -c 6 > > > > > > I have unmuted and set vol to high/max for pcm, front, surround, center > > > and lfe. I have set channel to 6ch. Everything else is muted. > > > > > > :-( > > > Hah! I managed it!!! Just tested with speaker-test, so far. I hacked the > driver a bit: > > In patch_analog.c in static int patch_ad1986a(struct hda_codec *codec) > > case AD1986A_3STACK: > spec->num_mixers = 2; > spec->mixers[1] = ad1986a_3st_mixers; > //spec->num_init_verbs = 3; > //spec->init_verbs[1] = ad1986a_3st_init_verbs; > //spec->init_verbs[2] = ad1986a_ch2_init; > spec->channel_mode = ad1986a_modes; > spec->num_channel_mode = ARRAY_SIZE(ad1986a_modes); > spec->need_dac_fix = 0;//1; > spec->multiout.max_channels = 6;//2; > spec->multiout.num_dacs = 3;//1; > break; > > I don't yet know whether it is completely correct what I did and what is the > minimal change needed. > > Perhaps some of the changes will lead to regressions, I need to check further. > > I think setting max channels and num_dacs has nor meaning, as probably the get > overwritten on ch set, right? dac_fix probably changes the way num_dacs are > assigned to? > > So my guess is that probably setting ad1986a_3st_init_verbs is wrong for my > mobo. > > {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, > {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, You're using older version. The latet HG version has different values there. Please try the HG version first then further debugging... Takashi |
From: Prakash P. <pr...@pu...> - 2007-04-16 14:51:35
|
Am Montag 16 April 2007 schrieb Takashi Iwai: > At Sat, 14 Apr 2007 11:24:49 +0200, > > Prakash Punnoor wrote: > > So my guess is that probably setting ad1986a_3st_init_verbs is wrong for > > my mobo. > > > > {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, > > {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, > > You're using older version. The latet HG version has different values > there. Please try the HG version first then further debugging... Nope doesn't work. I didn't put in complete hg drivers, just above part, as= : =2D-- /usr/src/linux/sound/pci/hda/patch_analog.c 2007-04-14 16:43:30.00000= 0000=20 +0200 +++ patch_analog.c 2007-04-16 16:38:48.000000000 +0200 @@ -192,6 +192,17 @@ return snd_hda_multi_out_dig_close(codec, &spec->multiout); } +static int ad198x_dig_playback_pcm_prepare(struct hda_pcm_stream *hinfo, + struct hda_codec *codec, + unsigned int stream_tag, + unsigned int format, + struct snd_pcm_substream=20 *substream) +{ + struct ad198x_spec *spec =3D codec->spec; + return snd_hda_multi_out_dig_prepare(codec, &spec->multiout,=20 stream_tag, + format, substream); +} + /* * Analog capture */ @@ -250,7 +261,8 @@ .nid =3D 0, /* fill later */ .ops =3D { .open =3D ad198x_dig_playback_pcm_open, =2D .close =3D ad198x_dig_playback_pcm_close + .close =3D ad198x_dig_playback_pcm_close, + .prepare =3D ad198x_dig_playback_pcm_prepare }, }; I don't think above matters as it looks spdif related. @@ -741,8 +753,9 @@ /* additional verbs for 3-stack model */ static struct hda_verb ad1986a_3st_init_verbs[] =3D { =2D /* Mic and line-in selectors */ =2D {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, + /* Mic selector, mix C/LFE (backmic) and Mic (frontmic) */ + {0x0f, AC_VERB_SET_CONNECT_SEL, 0x4}, + /* Line-in selectors */ {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, { } /* end */ }; Surround value is the same and it stays silent. center/lfe stays silent, as= =20 well. What now? =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Takashi I. <ti...@su...> - 2007-04-16 15:30:19
|
At Mon, 16 Apr 2007 16:51:21 +0200, Prakash Punnoor wrote: > > Am Montag 16 April 2007 schrieb Takashi Iwai: > > At Sat, 14 Apr 2007 11:24:49 +0200, > > > > Prakash Punnoor wrote: > > > So my guess is that probably setting ad1986a_3st_init_verbs is wrong for > > > my mobo. > > > > > > {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, > > > {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, > > > > You're using older version. The latet HG version has different values > > there. Please try the HG version first then further debugging... > > Nope doesn't work. I didn't put in complete hg drivers Why not? Anyway, if these verbs are harmful for your devices, we need to adjust it a bit. Try to comment out these verbs then confirm that the surround is working again. Then get the connection of the corresponding widgets from /proc/asound/card0/codec#* file and compare with the above values. Takashi |
From: Prakash P. <pr...@pu...> - 2007-04-16 17:03:55
|
Am Montag 16 April 2007 schrieb Takashi Iwai: > At Mon, 16 Apr 2007 16:51:21 +0200, > > Prakash Punnoor wrote: > > Am Montag 16 April 2007 schrieb Takashi Iwai: > > > At Sat, 14 Apr 2007 11:24:49 +0200, > > > > > > Prakash Punnoor wrote: > > > > So my guess is that probably setting ad1986a_3st_init_verbs is wrong > > > > for my mobo. > > > > > > > > {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, > > > > {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, > > > > > > You're using older version. The latet HG version has different values > > > there. Please try the HG version first then further debugging... > > > > Nope doesn't work. I didn't put in complete hg drivers > > Why not? > Because within 5 minutes I didn't find an easy way to deploy the hg tree in= to=20 kernel sources except copiying the directions to correct locations by=20 examining the kernel directory tree which is not very user friendly... > Anyway, if these verbs are harmful for your devices, we need to adjust > it a bit. Try to comment out these verbs then confirm that the > surround is working again.=20 It does. > Then get the connection of the=20 > corresponding widgets from /proc/asound/card0/codec#* file and compare > with the above values. Node 0x0f [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=3D0x00, nsteps=3D0x03, stepsize=3D0x27, mute=3D0 Amp-Out vals: [0x00 0x00] Connection: 8 0x1f* 0x20 0x1d 0x1d 0x27 0x28 0x29 0x2a Node 0x10 [Audio Selector] wcaps 0x300101: Stereo Connection: 3 0x20* 0x1c 0x1f Please remember, there is still the bug left, that when I change ch setting= , I=20 have to alter surr/center/lfe vol as they are otherwise muted. Hth, =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Takashi I. <ti...@su...> - 2007-04-16 17:41:17
|
At Mon, 16 Apr 2007 19:03:51 +0200, Prakash Punnoor wrote: > > Am Montag 16 April 2007 schrieb Takashi Iwai: > > At Mon, 16 Apr 2007 16:51:21 +0200, > > > > Prakash Punnoor wrote: > > > Am Montag 16 April 2007 schrieb Takashi Iwai: > > > > At Sat, 14 Apr 2007 11:24:49 +0200, > > > > > > > > Prakash Punnoor wrote: > > > > > So my guess is that probably setting ad1986a_3st_init_verbs is wrong > > > > > for my mobo. > > > > > > > > > > {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, > > > > > {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, > > > > > > > > You're using older version. The latet HG version has different values > > > > there. Please try the HG version first then further debugging... > > > > > > Nope doesn't work. I didn't put in complete hg drivers > > > > Why not? > > > > Because within 5 minutes I didn't find an easy way to deploy the hg tree into > kernel sources except copiying the directions to correct locations by > examining the kernel directory tree which is not very user friendly... > > > > Anyway, if these verbs are harmful for your devices, we need to adjust > > it a bit. Try to comment out these verbs then confirm that the > > surround is working again. > > It does. > > > Then get the connection of the > > corresponding widgets from /proc/asound/card0/codec#* file and compare > > with the above values. > > Node 0x0f [Audio Selector] wcaps 0x30010d: Stereo Amp-Out > Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 > Amp-Out vals: [0x00 0x00] > Connection: 8 > 0x1f* 0x20 0x1d 0x1d 0x27 0x28 0x29 0x2a > Node 0x10 [Audio Selector] wcaps 0x300101: Stereo > Connection: 3 > 0x20* 0x1c 0x1f > > Please remember, there is still the bug left, that when I change ch setting, I > have to alter surr/center/lfe vol as they are otherwise muted. Hmm, I can't follow the thread right now, so could you give a detailed problem description again, how to reproduce the problems? The widgets 0x0f and 0x10 are basically only for inputs (line and mic-in selections). Thus I'm wondering why these affects to outputs at all... Also, make sure that changing only these verbs do the same effect. That is, instead of commenting out, put 0 to the verbs for 0x0f and 0x10 in ad1986a_3st_init_verbs, and don't touch other lines. Takashi |
From: Trevor B. <tg...@sf...> - 2007-04-16 19:42:36
|
FYI, I'm eagerly watching this discussion as a user from the sidelines. I'll be happy to test out release candidates once they come out, but until then I don't want to mess with my(mostly) working settings. Keep going guys! Trevor Takashi Iwai wrote: > At Mon, 16 Apr 2007 20:42:10 +0200, > Prakash Punnoor wrote: > >> Am Montag 16 April 2007 schrieb Takashi Iwai: >> >>> At Mon, 16 Apr 2007 19:03:51 +0200, >>> >>> Prakash Punnoor wrote: >>> >>>> Am Montag 16 April 2007 schrieb Takashi Iwai: >>>> >>>>> At Mon, 16 Apr 2007 16:51:21 +0200, >>>>> >>>>> Prakash Punnoor wrote: >>>>> >>>>>> Am Montag 16 April 2007 schrieb Takashi Iwai: >>>>>> >>>>>>> At Sat, 14 Apr 2007 11:24:49 +0200, >>>>>>> >>>>>>> Prakash Punnoor wrote: >>>>>>> >>>>>>>> So my guess is that probably setting ad1986a_3st_init_verbs is >>>>>>>> wrong for my mobo. >>>>>>>> >>>>>>>> {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, >>>>>>>> {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, >>>>>>>> >>>>>>> You're using older version. The latet HG version has different >>>>>>> values there. Please try the HG version first then further >>>>>>> debugging... >>>>>>> >>>>>> Nope doesn't work. I didn't put in complete hg drivers >>>>>> >>>>> Why not? >>>>> >>>> Because within 5 minutes I didn't find an easy way to deploy the hg tree >>>> into kernel sources except copiying the directions to correct locations >>>> by examining the kernel directory tree which is not very user friendly... >>>> >>>> >>>>> Anyway, if these verbs are harmful for your devices, we need to adjust >>>>> it a bit. Try to comment out these verbs then confirm that the >>>>> surround is working again. >>>>> >>>> It does. >>>> >>>> >>>>> Then get the connection of the >>>>> corresponding widgets from /proc/asound/card0/codec#* file and compare >>>>> with the above values. >>>>> >>>> Node 0x0f [Audio Selector] wcaps 0x30010d: Stereo Amp-Out >>>> Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 >>>> Amp-Out vals: [0x00 0x00] >>>> Connection: 8 >>>> 0x1f* 0x20 0x1d 0x1d 0x27 0x28 0x29 0x2a >>>> Node 0x10 [Audio Selector] wcaps 0x300101: Stereo >>>> Connection: 3 >>>> 0x20* 0x1c 0x1f >>>> >>>> Please remember, there is still the bug left, that when I change ch >>>> setting, I have to alter surr/center/lfe vol as they are otherwise muted. >>>> >>> Hmm, I can't follow the thread right now, so could you give a detailed >>> problem description again, how to reproduce the problems? >>> >> With 2.6.21-rc6, surr and center/lfe remain silent, regardless of alsamixer >> setting. When I patch ad1986a_3st_init_verbs out, it works. >> >> Another related bug is above: >> >> >>>> Please remember, there is still the bug left, that when I change ch >>>> setting, I have to alter surr/center/lfe vol as they are otherwise muted. >>>> >> I guess writing 0xb000 is not enough, as the lower 6 bits are gain value. Or >> does the gain get applied somewhere else? >> > > It corresponds to "Mic Boost" control. > > >>> The widgets 0x0f and 0x10 are basically only for inputs (line and >>> mic-in selections). Thus I'm wondering why these affects to outputs >>> at all... >>> >> Well, I am not sure how to read the specs: >> >> 0x0f Chooses the mic inputs betweeb the MIC_1/2 and C/LFE pins. Contains the >> mic gain boost amp. >> >> 0x10 Chooses the line in inputs between the line in, surround and MIC_1/2 >> pins. >> >> I think with those NIDs you actually select between "I want line in" or "I >> want surround out" and whatever. >> > > It sounds like so although it's just a guess work. > > >> I remeber having troubles capturing sound via mic in or line in using audacity >> alsa driver. I only managed it with audacity oss driver (with alsa oss kernel >> emu). I guess this is related to wrong setting of above NIDs? >> > > Maybe. The 0x0f and 0x10 are really mysterious setting on AD1986A. > > >>> Also, make sure that changing only these verbs do the same effect. >>> That is, instead of commenting out, put 0 to the verbs for 0x0f and >>> 0x10 in ad1986a_3st_init_verbs, and don't touch other lines. >>> >> This works, I get sound. >> > > Then, we seems to need reset 0x0f and 0x10 at each channel setting. > Try the patch below. This will reset 0x0f and 0x10 to 0 when 6ch > channel mode is chosen. On 2ch channel mode, these values should be > back to make mic and line working (and no surround outputs, of > course). > > > Takashi > > diff -r 4b6ed4ef4820 pci/hda/patch_analog.c > --- a/pci/hda/patch_analog.c Mon Apr 16 19:20:17 2007 +0200 > +++ b/pci/hda/patch_analog.c Mon Apr 16 21:07:45 2007 +0200 > @@ -764,9 +764,11 @@ static struct hda_verb ad1986a_ch2_init[ > /* Surround out -> Line In */ > { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x24 }, > { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, 0xb080}, > + { 0x10, AC_VERB_SET_CONNECT_SEL, 0x1 }, > /* CLFE -> Mic in */ > { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x24 }, > { 0x1d, AC_VERB_SET_AMP_GAIN_MUTE, 0xb080}, > + { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x4 }, > { } /* end */ > }; > > @@ -774,9 +776,11 @@ static struct hda_verb ad1986a_ch4_init[ > /* Surround out -> Surround */ > { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x40 }, > { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000}, > + { 0x10, AC_VERB_SET_CONNECT_SEL, 0x0 }, > /* CLFE -> Mic in */ > { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x24 }, > { 0x1d, AC_VERB_SET_AMP_GAIN_MUTE, 0xb080}, > + { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x4 }, > { } /* end */ > }; > > @@ -784,9 +788,11 @@ static struct hda_verb ad1986a_ch6_init[ > /* Surround out -> Surround out */ > { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x40 }, > { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000}, > + { 0x10, AC_VERB_SET_CONNECT_SEL, 0x0 }, > /* CLFE -> CLFE */ > { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x40 }, > { 0x1d, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000}, > + { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x0 }, > { } /* end */ > }; > > |
From: Prakash P. <pr...@pu...> - 2007-04-16 18:42:24
|
Am Montag 16 April 2007 schrieb Takashi Iwai: > At Mon, 16 Apr 2007 19:03:51 +0200, > > Prakash Punnoor wrote: > > Am Montag 16 April 2007 schrieb Takashi Iwai: > > > At Mon, 16 Apr 2007 16:51:21 +0200, > > > > > > Prakash Punnoor wrote: > > > > Am Montag 16 April 2007 schrieb Takashi Iwai: > > > > > At Sat, 14 Apr 2007 11:24:49 +0200, > > > > > > > > > > Prakash Punnoor wrote: > > > > > > So my guess is that probably setting ad1986a_3st_init_verbs is > > > > > > wrong for my mobo. > > > > > > > > > > > > {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, > > > > > > {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, > > > > > > > > > > You're using older version. The latet HG version has different > > > > > values there. Please try the HG version first then further > > > > > debugging... > > > > > > > > Nope doesn't work. I didn't put in complete hg drivers > > > > > > Why not? > > > > Because within 5 minutes I didn't find an easy way to deploy the hg tree > > into kernel sources except copiying the directions to correct locations > > by examining the kernel directory tree which is not very user friendly.= =2E. > > > > > Anyway, if these verbs are harmful for your devices, we need to adjust > > > it a bit. Try to comment out these verbs then confirm that the > > > surround is working again. > > > > It does. > > > > > Then get the connection of the > > > corresponding widgets from /proc/asound/card0/codec#* file and compare > > > with the above values. > > > > Node 0x0f [Audio Selector] wcaps 0x30010d: Stereo Amp-Out > > Amp-Out caps: ofs=3D0x00, nsteps=3D0x03, stepsize=3D0x27, mute=3D0 > > Amp-Out vals: [0x00 0x00] > > Connection: 8 > > 0x1f* 0x20 0x1d 0x1d 0x27 0x28 0x29 0x2a > > Node 0x10 [Audio Selector] wcaps 0x300101: Stereo > > Connection: 3 > > 0x20* 0x1c 0x1f > > > > Please remember, there is still the bug left, that when I change ch > > setting, I have to alter surr/center/lfe vol as they are otherwise mute= d. > > Hmm, I can't follow the thread right now, so could you give a detailed > problem description again, how to reproduce the problems? With 2.6.21-rc6, surr and center/lfe remain silent, regardless of alsamixer= =20 setting. When I patch ad1986a_3st_init_verbs out, it works. Another related bug is above: > > Please remember, there is still the bug left, that when I change ch > > setting, I have to alter surr/center/lfe vol as they are otherwise mute= d. I guess writing 0xb000 is not enough, as the lower 6 bits are gain value. O= r=20 does the gain get applied somewhere else? > The widgets 0x0f and 0x10 are basically only for inputs (line and > mic-in selections). Thus I'm wondering why these affects to outputs > at all... Well, I am not sure how to read the specs: 0x0f Chooses the mic inputs betweeb the MIC_1/2 and C/LFE pins. Contains th= e=20 mic gain boost amp. 0x10 Chooses the line in inputs between the line in, surround and MIC_1/2=20 pins. I think with those NIDs you actually select between "I want line in" or "I= =20 want surround out" and whatever. I remeber having troubles capturing sound via mic in or line in using audac= ity=20 alsa driver. I only managed it with audacity oss driver (with alsa oss kern= el=20 emu). I guess this is related to wrong setting of above NIDs? > Also, make sure that changing only these verbs do the same effect. > That is, instead of commenting out, put 0 to the verbs for 0x0f and > 0x10 in ad1986a_3st_init_verbs, and don't touch other lines. This works, I get sound. =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Takashi I. <ti...@su...> - 2007-04-16 19:13:13
|
At Mon, 16 Apr 2007 20:42:10 +0200, Prakash Punnoor wrote: > > Am Montag 16 April 2007 schrieb Takashi Iwai: > > At Mon, 16 Apr 2007 19:03:51 +0200, > > > > Prakash Punnoor wrote: > > > Am Montag 16 April 2007 schrieb Takashi Iwai: > > > > At Mon, 16 Apr 2007 16:51:21 +0200, > > > > > > > > Prakash Punnoor wrote: > > > > > Am Montag 16 April 2007 schrieb Takashi Iwai: > > > > > > At Sat, 14 Apr 2007 11:24:49 +0200, > > > > > > > > > > > > Prakash Punnoor wrote: > > > > > > > So my guess is that probably setting ad1986a_3st_init_verbs is > > > > > > > wrong for my mobo. > > > > > > > > > > > > > > {0x0f, AC_VERB_SET_CONNECT_SEL, 0x2}, > > > > > > > {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, > > > > > > > > > > > > You're using older version. The latet HG version has different > > > > > > values there. Please try the HG version first then further > > > > > > debugging... > > > > > > > > > > Nope doesn't work. I didn't put in complete hg drivers > > > > > > > > Why not? > > > > > > Because within 5 minutes I didn't find an easy way to deploy the hg tree > > > into kernel sources except copiying the directions to correct locations > > > by examining the kernel directory tree which is not very user friendly... > > > > > > > Anyway, if these verbs are harmful for your devices, we need to adjust > > > > it a bit. Try to comment out these verbs then confirm that the > > > > surround is working again. > > > > > > It does. > > > > > > > Then get the connection of the > > > > corresponding widgets from /proc/asound/card0/codec#* file and compare > > > > with the above values. > > > > > > Node 0x0f [Audio Selector] wcaps 0x30010d: Stereo Amp-Out > > > Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 > > > Amp-Out vals: [0x00 0x00] > > > Connection: 8 > > > 0x1f* 0x20 0x1d 0x1d 0x27 0x28 0x29 0x2a > > > Node 0x10 [Audio Selector] wcaps 0x300101: Stereo > > > Connection: 3 > > > 0x20* 0x1c 0x1f > > > > > > Please remember, there is still the bug left, that when I change ch > > > setting, I have to alter surr/center/lfe vol as they are otherwise muted. > > > > Hmm, I can't follow the thread right now, so could you give a detailed > > problem description again, how to reproduce the problems? > > With 2.6.21-rc6, surr and center/lfe remain silent, regardless of alsamixer > setting. When I patch ad1986a_3st_init_verbs out, it works. > > Another related bug is above: > > > > Please remember, there is still the bug left, that when I change ch > > > setting, I have to alter surr/center/lfe vol as they are otherwise muted. > > I guess writing 0xb000 is not enough, as the lower 6 bits are gain value. Or > does the gain get applied somewhere else? It corresponds to "Mic Boost" control. > > The widgets 0x0f and 0x10 are basically only for inputs (line and > > mic-in selections). Thus I'm wondering why these affects to outputs > > at all... > > Well, I am not sure how to read the specs: > > 0x0f Chooses the mic inputs betweeb the MIC_1/2 and C/LFE pins. Contains the > mic gain boost amp. > > 0x10 Chooses the line in inputs between the line in, surround and MIC_1/2 > pins. > > I think with those NIDs you actually select between "I want line in" or "I > want surround out" and whatever. It sounds like so although it's just a guess work. > I remeber having troubles capturing sound via mic in or line in using audacity > alsa driver. I only managed it with audacity oss driver (with alsa oss kernel > emu). I guess this is related to wrong setting of above NIDs? Maybe. The 0x0f and 0x10 are really mysterious setting on AD1986A. > > Also, make sure that changing only these verbs do the same effect. > > That is, instead of commenting out, put 0 to the verbs for 0x0f and > > 0x10 in ad1986a_3st_init_verbs, and don't touch other lines. > > This works, I get sound. Then, we seems to need reset 0x0f and 0x10 at each channel setting. Try the patch below. This will reset 0x0f and 0x10 to 0 when 6ch channel mode is chosen. On 2ch channel mode, these values should be back to make mic and line working (and no surround outputs, of course). Takashi diff -r 4b6ed4ef4820 pci/hda/patch_analog.c --- a/pci/hda/patch_analog.c Mon Apr 16 19:20:17 2007 +0200 +++ b/pci/hda/patch_analog.c Mon Apr 16 21:07:45 2007 +0200 @@ -764,9 +764,11 @@ static struct hda_verb ad1986a_ch2_init[ /* Surround out -> Line In */ { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x24 }, { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, 0xb080}, + { 0x10, AC_VERB_SET_CONNECT_SEL, 0x1 }, /* CLFE -> Mic in */ { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x24 }, { 0x1d, AC_VERB_SET_AMP_GAIN_MUTE, 0xb080}, + { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x4 }, { } /* end */ }; @@ -774,9 +776,11 @@ static struct hda_verb ad1986a_ch4_init[ /* Surround out -> Surround */ { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x40 }, { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000}, + { 0x10, AC_VERB_SET_CONNECT_SEL, 0x0 }, /* CLFE -> Mic in */ { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x24 }, { 0x1d, AC_VERB_SET_AMP_GAIN_MUTE, 0xb080}, + { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x4 }, { } /* end */ }; @@ -784,9 +788,11 @@ static struct hda_verb ad1986a_ch6_init[ /* Surround out -> Surround out */ { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x40 }, { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000}, + { 0x10, AC_VERB_SET_CONNECT_SEL, 0x0 }, /* CLFE -> CLFE */ { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x40 }, { 0x1d, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000}, + { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x0 }, { } /* end */ }; |
From: Prakash P. <pr...@pu...> - 2007-04-17 15:41:07
|
Am Montag 16 April 2007 schrieb Takashi Iwai: > At Mon, 16 Apr 2007 20:42:10 +0200, > > I guess writing 0xb000 is not enough, as the lower 6 bits are gain valu= e. > > Or does the gain get applied somewhere else? > > It corresponds to "Mic Boost" control. I don't get it. I am referring to: { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000}, Looking at the spec, it tells me your are setting output amp, left and righ= t=20 to unmuted state with 0 gain. (BTW, what about using more readable values? I thought drivers should be=20 written with less magic numbers? IE: #define OUT_AMP (1<<15) #define LEFT_AMP (1<<13) #define RIGHT_AMP (1<<12) #define MUTE_AMP (1<<7) Then we would have { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, OUT_AMP|LEFT_AMP|RIGHT_AMP}, and=20 { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, OUT_AMP|LEFT_AMP|RIGHT_AMP| MUTE_AMP}, instead of 0xb080 magic number when muting the plug....) > > Well, I am not sure how to read the specs: > > > > 0x0f Chooses the mic inputs betweeb the MIC_1/2 and C/LFE pins. Contains > > the mic gain boost amp. > > > > 0x10 Chooses the line in inputs between the line in, surround and MIC_1= /2 > > pins. > > > > I think with those NIDs you actually select between "I want line in" or > > "I want surround out" and whatever. > > It sounds like so although it's just a guess work. > > > I remeber having troubles capturing sound via mic in or line in using > > audacity alsa driver. I only managed it with audacity oss driver (with > > alsa oss kernel emu). I guess this is related to wrong setting of above > > NIDs? > > Maybe. The 0x0f and 0x10 are really mysterious setting on AD1986A. When I find time I'll test the capture again and if it doesn't work, play w= ith=20 those NIDs. > Then, we seems to need reset 0x0f and 0x10 at each channel setting. > Try the patch below. This will reset 0x0f and 0x10 to 0 when 6ch > channel mode is chosen. On 2ch channel mode, these values should be > back to make mic and line working (and no surround outputs, of > course). Patch works for me. Just the "volume is 0 on ch setting change" bug left. =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Takashi I. <ti...@su...> - 2007-04-17 16:02:08
|
At Tue, 17 Apr 2007 17:40:04 +0200, Prakash Punnoor wrote: > > Am Montag 16 April 2007 schrieb Takashi Iwai: > > At Mon, 16 Apr 2007 20:42:10 +0200, > > > I guess writing 0xb000 is not enough, as the lower 6 bits are gain value. > > > Or does the gain get applied somewhere else? > > > > It corresponds to "Mic Boost" control. > > I don't get it. I am referring to: > > { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000}, I thought you referring 0x0f. 0x1c corresponds to Surround Playback {Volume|Switch}. > Looking at the spec, it tells me your are setting output amp, left and right > to unmuted state with 0 gain. Yes, intentionally done so. The default values are muted. > (BTW, what about using more readable values? I thought drivers should be > written with less magic numbers? IE: > > #define OUT_AMP (1<<15) > #define LEFT_AMP (1<<13) > #define RIGHT_AMP (1<<12) > #define MUTE_AMP (1<<7) It's AMP_OUT_MUTE. The driver was written before the macro. > > > Then, we seems to need reset 0x0f and 0x10 at each channel setting. > > Try the patch below. This will reset 0x0f and 0x10 to 0 when 6ch > > channel mode is chosen. On 2ch channel mode, these values should be > > back to make mic and line working (and no surround outputs, of > > course). > > Patch works for me. Just the "volume is 0 on ch setting change" bug left. Did you unmute and adjust surround and CLFE volumes properly beforehand? Takashi |
From: Prakash P. <pr...@pu...> - 2007-04-17 17:40:09
|
Am Dienstag 17 April 2007 schrieb Takashi Iwai: > At Tue, 17 Apr 2007 17:40:04 +0200, > > Patch works for me. Just the "volume is 0 on ch setting change" bug lef= t. > > Did you unmute and adjust surround and CLFE volumes properly > beforehand? Yes, of course... =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |
From: Takashi I. <ti...@su...> - 2007-04-18 10:19:15
|
At Tue, 17 Apr 2007 19:40:02 +0200, Prakash Punnoor wrote: > > [1 <text/plain; iso-8859-1 (quoted-printable)>] > Am Dienstag 17 April 2007 schrieb Takashi Iwai: > > At Tue, 17 Apr 2007 17:40:04 +0200, > > > > Patch works for me. Just the "volume is 0 on ch setting change" bug left. > > > > Did you unmute and adjust surround and CLFE volumes properly > > beforehand? > > Yes, of course... OK then how about the patch below? Takashi diff -r ec904302b979 pci/hda/patch_analog.c --- a/pci/hda/patch_analog.c Tue Apr 17 15:41:52 2007 +0200 +++ b/pci/hda/patch_analog.c Wed Apr 18 12:15:34 2007 +0200 @@ -751,42 +751,35 @@ static struct hda_verb ad1986a_init_verb { } /* end */ }; -/* additional verbs for 3-stack model */ -static struct hda_verb ad1986a_3st_init_verbs[] = { - /* Mic selector, mix C/LFE (backmic) and Mic (frontmic) */ - {0x0f, AC_VERB_SET_CONNECT_SEL, 0x4}, - /* Line-in selectors */ - {0x10, AC_VERB_SET_CONNECT_SEL, 0x1}, - { } /* end */ -}; - static struct hda_verb ad1986a_ch2_init[] = { /* Surround out -> Line In */ - { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x24 }, - { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, 0xb080}, + { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN }, + /* Line-in selectors */ + { 0x10, AC_VERB_SET_CONNECT_SEL, 0x1 }, /* CLFE -> Mic in */ - { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x24 }, - { 0x1d, AC_VERB_SET_AMP_GAIN_MUTE, 0xb080}, + { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREF80 }, + /* Mic selector, mix C/LFE (backmic) and Mic (frontmic) */ + { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x4 }, { } /* end */ }; static struct hda_verb ad1986a_ch4_init[] = { /* Surround out -> Surround */ - { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x40 }, - { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000}, + { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT }, + { 0x10, AC_VERB_SET_CONNECT_SEL, 0x0 }, /* CLFE -> Mic in */ - { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x24 }, - { 0x1d, AC_VERB_SET_AMP_GAIN_MUTE, 0xb080}, + { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREF80 }, + { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x4 }, { } /* end */ }; static struct hda_verb ad1986a_ch6_init[] = { /* Surround out -> Surround out */ - { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x40 }, - { 0x1c, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000}, + { 0x1c, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT }, + { 0x10, AC_VERB_SET_CONNECT_SEL, 0x0 }, /* CLFE -> CLFE */ - { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, 0x40 }, - { 0x1d, AC_VERB_SET_AMP_GAIN_MUTE, 0xb000}, + { 0x1d, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT }, + { 0x0f, AC_VERB_SET_CONNECT_SEL, 0x0 }, { } /* end */ }; @@ -895,9 +888,8 @@ static int patch_ad1986a(struct hda_code case AD1986A_3STACK: spec->num_mixers = 2; spec->mixers[1] = ad1986a_3st_mixers; - spec->num_init_verbs = 3; - spec->init_verbs[1] = ad1986a_3st_init_verbs; - spec->init_verbs[2] = ad1986a_ch2_init; + spec->num_init_verbs = 2; + spec->init_verbs[1] = ad1986a_ch2_init; spec->channel_mode = ad1986a_modes; spec->num_channel_mode = ARRAY_SIZE(ad1986a_modes); spec->need_dac_fix = 1; |
From: Prakash P. <pr...@pu...> - 2007-04-18 17:15:20
|
Am Mittwoch 18 April 2007 schrieb Takashi Iwai: > At Tue, 17 Apr 2007 19:40:02 +0200, > > Prakash Punnoor wrote: > > [1 <text/plain; iso-8859-1 (quoted-printable)>] > > > > Am Dienstag 17 April 2007 schrieb Takashi Iwai: > > > At Tue, 17 Apr 2007 17:40:04 +0200, > > > > > > > Patch works for me. Just the "volume is 0 on ch setting change" bug > > > > left. > > > > > > Did you unmute and adjust surround and CLFE volumes properly > > > beforehand? > > > > Yes, of course... > > OK then how about the patch below? Yes, works! surround and c/lfe work and the "volume bug" is gone. Very nice= =2E=20 Could we get this pushed into 2.6.21? Note that your patch doesn't apply cleanly to 2.6.21-rc6, though. =2D-=20 (=B0=3D =3D=B0) //\ Prakash Punnoor /\\ V_/ \_V |