Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Sean Burke]

A quick google shows that the vendor ID is Cirrus Logic. The Boot Camp 
driver set does include installers for Cirrus audio cards. I don't have 
Windows installed on here, so I can't check to see if it is indeed the 
Cirrus drivers that get installed. What can be done to facilitate the 
implementation of this codec?


Sean

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Mon, 29 Jun 2009 16:04:06 -0600,
Sean Burke wrote:
> 
> A quick google shows that the vendor ID is Cirrus Logic. The Boot Camp 
> driver set does include installers for Cirrus audio cards. I don't have 
> Windows installed on here, so I can't check to see if it is indeed the 
> Cirrus drivers that get installed. What can be done to facilitate the 
> implementation of this codec?

I guess it's CS4206 codec.  CS4207 has a different id.

If it doesn't use any vendor-specific verbs, the implementation
wouldn't be too difficult.


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Andreas Nüßlein]

so i tried to find some information in OS X and after a while i stumbled upon a 
document "Info.plist", to which i was pointed by OS X's build-in hardware 
info-utility, somehwere in /System/Library/Extensions/AppleHDA.kext/....  

http://nopaste.org/p/aRCCwdDXqb

also some information right out of the apple tool, eventhough i don't think 
that it's worth anything:
Intel High Definition Audio:                                                                         
  Device ID:    0x10DECB79
  Audio ID:     77        
  Available Devices:      
  Headphone:              
  Connection:   Combo     
  Speaker:                
  Connection:   Internal  
  Line In:                
  Connection:   Combo     
  Internal Microphone:    
  Connection:   Internal  
  S/P-DIF Out:            
  Connection:   Combo     
  External Microphone:    
  Connection:   Combo   


On Tuesday 30 June 2009 07:58:17 Takashi Iwai wrote:
> At Mon, 29 Jun 2009 16:04:06 -0600,
>
> Sean Burke wrote:
> > A quick google shows that the vendor ID is Cirrus Logic. The Boot Camp
> > driver set does include installers for Cirrus audio cards. I don't have
> > Windows installed on here, so I can't check to see if it is indeed the
> > Cirrus drivers that get installed. What can be done to facilitate the
> > implementation of this codec?
>
> I guess it's CS4206 codec.  CS4207 has a different id.

out of the Info.plist:
<string>Cirrus Logic CS4206</string>                          
<key>CodecID</key>


so again: if i can, i'd love to help.


thanks a lot

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Wed, 1 Jul 2009 17:00:42 +0200,
Andreas Nüßlein wrote:
> 
> 
> so i tried to find some information in OS X and after a while i stumbled upon a 
> document "Info.plist", to which i was pointed by OS X's build-in hardware 
> info-utility, somehwere in /System/Library/Extensions/AppleHDA.kext/....  
> 
> http://nopaste.org/p/aRCCwdDXqb
> 
> also some information right out of the apple tool, eventhough i don't think 
> that it's worth anything:
> Intel High Definition Audio:                                                                         
>   Device ID:    0x10DECB79

This is likely a different chip.

> 
> On Tuesday 30 June 2009 07:58:17 Takashi Iwai wrote:
> > At Mon, 29 Jun 2009 16:04:06 -0600,
> >
> > Sean Burke wrote:
> > > A quick google shows that the vendor ID is Cirrus Logic. The Boot Camp
> > > driver set does include installers for Cirrus audio cards. I don't have
> > > Windows installed on here, so I can't check to see if it is indeed the
> > > Cirrus drivers that get installed. What can be done to facilitate the
> > > implementation of this codec?
> >
> > I guess it's CS4206 codec.  CS4207 has a different id.
> 
> out of the Info.plist:
> <string>Cirrus Logic CS4206</string>                          
> <key>CodecID</key>

And that's it.

> so again: if i can, i'd love to help.

I created the support for for Cirrus Logic chips (cs420x only).
It's included in sound-unstable tree.  Grab the alsa-driver-unstable
snapshot from
  ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz

Let me know if it works or not.

Also, prepare to install hda-verb program.  I'd like to confirm the
behavior of the codec, and I'll ask it later once after the driver
works somehow.


thanks,

Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Andreas Nüßlein]

[-- Attachment #1.1: Type: text/plain, Size: 1123 bytes --]

wow thanks a lot! =)

> ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-uns
>table-snapshot.tar.gz
>
> Let me know if it works or not.

sadly: no.. well the chip gets recognized now:
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 0: Cirrus Analog [Cirrus Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

and alsamixer also shows a bunch of channels now as well as 
"Card: HDA NVidia                                                                                                                                            
Chip: Cirrus Logic CS4206"

but i can't get any sound eventhough all channels are unmuted and turned up to 
100.

i also aplay -Dfoo file.wav again, where foo = default,front,surround40,.... , 
but i always get: aplay: main:608: audio open error: Invalid argument

> Also, prepare to install hda-verb program.  I'd like to confirm the
> behavior of the codec, and I'll ask it later once after the driver
> works somehow.

installing hda-verb and waiting for orders ;)



thanks a lot

nutz

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Thu, 2 Jul 2009 12:54:47 +0200,
Andreas Nüßlein wrote:
> 
> wow thanks a lot! =)
> 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-uns
> >table-snapshot.tar.gz
> >
> > Let me know if it works or not.
> 
> sadly: no.. well the chip gets recognized now:
> $ aplay -l
> **** List of PLAYBACK Hardware Devices ****
> card 0: NVidia [HDA NVidia], device 0: Cirrus Analog [Cirrus Analog]
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> 
> and alsamixer also shows a bunch of channels now as well as 
> "Card: HDA NVidia                                                                                                                                            
> Chip: Cirrus Logic CS4206"
> 
> but i can't get any sound eventhough all channels are unmuted and turned up to 
> 100.

Please run alsa-info.sh with --no-upload option, and attach the
generated file.


thanks,

Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Thu, 2 Jul 2009 12:54:47 +0200,
Andreas Nüßlein wrote:
> 
> but i can't get any sound eventhough all channels are unmuted and turned up to 
> 100.
> 
> i also aplay -Dfoo file.wav again, where foo = default,front,surround40,.... , 
> but i always get: aplay: main:608: audio open error: Invalid argument

The error is strange.  Did you build with --enable-dynamic-minors
configure option?

Otherwise the codec registers look OK.


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Andreas Nüßlein]

On Thursday 02 July 2009 15:15:34 you wrote:
> At Thu, 2 Jul 2009 12:54:47 +0200,
>
> Andreas Nüßlein wrote:
> > but i can't get any sound eventhough all channels are unmuted and turned
> > up to 100.
> >
> > i also aplay -Dfoo file.wav again, where foo =
> > default,front,surround40,.... , but i always get: aplay: main:608: audio
> > open error: Invalid argument
>
> The error is strange.  Did you build with --enable-dynamic-minors
> configure option?
>
> Otherwise the codec registers look OK.
>


hmmm.. well whenever i really build this manually ( ./configure --with-
cards=hda-intel && make && sudo make install)  i can't load the modules, 
because i get:
[ 1526.091642] snd: Unknown symbol unregister_sound_special                                                          
[ 1526.092374] snd: Unknown symbol register_sound_special_device  

however when i edited the gentoo-ebuild to use your snapshot, i'm able to 
compile and load the driver but get said error. 

do you have an idea why i'm getting this Unknown symbol -error?  should i 
build alsa-headers myself as well? right now that's built via gentoo-ebuild.

i'll try to copy the ebuild instructions, step by step until i get it running 
manually.

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Thu, 2 Jul 2009 19:37:43 +0200,
Andreas Nüßlein wrote:
> 
> On Thursday 02 July 2009 15:15:34 you wrote:
> > At Thu, 2 Jul 2009 12:54:47 +0200,
> >
> > Andreas Nüßlein wrote:
> > > but i can't get any sound eventhough all channels are unmuted and turned
> > > up to 100.
> > >
> > > i also aplay -Dfoo file.wav again, where foo =
> > > default,front,surround40,.... , but i always get: aplay: main:608: audio
> > > open error: Invalid argument
> >
> > The error is strange.  Did you build with --enable-dynamic-minors
> > configure option?
> >
> > Otherwise the codec registers look OK.
> >
> 
> 
> hmmm.. well whenever i really build this manually ( ./configure --with-
> cards=hda-intel && make && sudo make install)  i can't load the modules, 
> because i get:
> [ 1526.091642] snd: Unknown symbol unregister_sound_special                                                          
> [ 1526.092374] snd: Unknown symbol register_sound_special_device  

You should use
	./configure --with-debug=full --enable-dynamic-minors \
		--with-moddir=updates

> however when i edited the gentoo-ebuild to use your snapshot, i'm able to 
> compile and load the driver but get said error. 
> 
> do you have an idea why i'm getting this Unknown symbol -error?  should i 
> build alsa-headers myself as well? right now that's built via gentoo-ebuild.

I have no idea a about gentoo.


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Andreas Nüßlein]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

On Friday 03 July 2009 07:37:59 you wrote:
> At Thu, 2 Jul 2009 19:37:43 +0200,
>
> Andreas Nüßlein wrote:
> > On Thursday 02 July 2009 15:15:34 you wrote:
> > > At Thu, 2 Jul 2009 12:54:47 +0200,
> > >
> > > Andreas Nüßlein wrote:
> > > > but i can't get any sound eventhough all channels are unmuted and
> > > > turned up to 100.
> > > >
> > > > i also aplay -Dfoo file.wav again, where foo =
> > > > default,front,surround40,.... , but i always get: aplay: main:608:
> > > > audio open error: Invalid argument
> > >
> > > The error is strange.  Did you build with --enable-dynamic-minors
> > > configure option?
> > >
> > > Otherwise the codec registers look OK.
> >
> > hmmm.. well whenever i really build this manually ( ./configure --with-
> > cards=hda-intel && make && sudo make install)  i can't load the modules,
> > because i get:
> > [ 1526.091642] snd: Unknown symbol unregister_sound_special
> > [ 1526.092374] snd: Unknown symbol register_sound_special_device
>

so i finally figured out, the problem with "Unknown symbol 
unregister_sound_special":  the ebuild always used "--without-oss". as soon as 
i applied that to my manual ./configure i was able to load the modules. however 
now dmesg throws some errors - i attached them to this mail. i'm a little 
confused why there's still my build-dir in the errors, 


[-- Attachment #2: dmesg_tail.txt --]
[-- Type: text/plain, Size: 1450 bytes --]

[30518.015451] HDA Intel 0000:00:08.0: PCI INT A -> Link[LAZA] -> GSI 23 (level, low) -> IRQ 23
[30518.015513] HDA Intel 0000:00:08.0: setting latency timer to 64
[30518.176350] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3844: autoconfig: line_outs=1 (0xa/0x0/0x0/0x0/0x0)
[30518.176366] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3848:    speaker_outs=1 (0xb/0x0/0x0/0x0/0x0)
[30518.176379] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3852:    hp_outs=1 (0x9/0x0/0x0/0x0/0x0)
[30518.176391] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3853:    mono: mono_out=0x0
[30518.176401] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3856:    dig-out=0x10/0x15
[30518.176411] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3864:    inputs: mic=0xd, fmic=0x0, line=0xc, fline=0x0, cd=0x0, aux=0x0
[30518.176425] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3866:    dig-in=0x12
[30518.479301] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/acore/pcm_native.c:2056: snd_pcm_hw_constraints_complete failed
[30518.479750] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/acore/pcm_native.c:2056: snd_pcm_hw_constraints_complete failed

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Fri, 3 Jul 2009 13:25:06 +0200,
Andreas Nüßlein wrote:
> 
> [30518.015451] HDA Intel 0000:00:08.0: PCI INT A -> Link[LAZA] -> GSI 23 (level, low) -> IRQ 23
> [30518.015513] HDA Intel 0000:00:08.0: setting latency timer to 64
> [30518.176350] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3844: autoconfig: line_outs=1 (0xa/0x0/0x0/0x0/0x0)
> [30518.176366] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3848:    speaker_outs=1 (0xb/0x0/0x0/0x0/0x0)
> [30518.176379] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3852:    hp_outs=1 (0x9/0x0/0x0/0x0/0x0)
> [30518.176391] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3853:    mono: mono_out=0x0
> [30518.176401] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3856:    dig-out=0x10/0x15
> [30518.176411] ALSA /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:3864:    inputs: mic=0xd, fmic=0x0, line=0xc, fline=0x0, cd=0x0, aux=0x0

Now yours looks different from others.  In your earlier one, it was
two line-outs (they are speakers, though).  Now it's one line-out
and speaker...

Could you give alsa-info.sh output?


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Andreas Nüßlein]

[-- Attachment #1.1: Type: text/plain, Size: 8321 bytes --]

On Monday 06 July 2009 15:39:09 you wrote:
> At Mon, 6 Jul 2009 14:59:09 +0200,
>
> Andreas Nüßlein wrote:
> > On Monday 06 July 2009 14:44:56 you wrote:
> > > At Mon, 6 Jul 2009 12:19:11 +0200,
> > >
> > > Andreas Nüßlein wrote:
> > > > On Monday 06 July 2009 12:08:11 you wrote:
> > > > > At Mon, 6 Jul 2009 11:45:07 +0200,
> > > > >
> > > > > Andreas Nüßlein wrote:
> > > > > > [1  <text/plain; iso-8859-1 (quoted-printable)>]
> > > > > >
> > > > > > On Monday 06 July 2009 09:23:07 you wrote:
> > > > > > > At Sun, 5 Jul 2009 12:30:52 +0200,
> > > > > > >
> > > > > > > > however i was able to reproduce the "bad kfree", by changing
> > > > > > > > the volumes in alsamixer. it always gave me the same "called
> > > > > > > > from ID" so i tried "while (true) do cat /proc/kallsyms |
> > > > > > > > grep ffffffffa001b08b; done" and then changed the volume, but
> > > > > > > > the grep never returned anything, dmesg of course got more
> > > > > > > > and more of those kfree-errors.
> > > > > > >
> > > > > > > The address won't match exactly in /proc/kasllsyms.
> > > > > > > But you can guess which function by address.  First sort
> > > > > > > /proc/kallsyms then check the position that fits with the given
> > > > > > > address.
> > > > > > >
> > > > > > >
> > > > > > > Takashi
> > > > > >
> > > > > > well i'm not really sure _I_ can guess ;)    i guess it's either
> > > > > > "t snd_ctl_ioctl        [snd]" or  "t snd_ctl_ioctl_compat
> > > > > > [snd]".
> > > > > >
> > > > > > here are the greps, "snd: bad kfree (called from
> > > > > > ffffffffa001b08b)" being the error:
> > > > > >
> > > > > >
> > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001a
> > > > > > ffffffffa001a045 t snd_ctl_elem_info    [snd]
> > > > > > ffffffffa001a17a t copy_ctl_value_from_user     [snd]
> > > > > > ffffffffa001a34f t snd_ctl_elem_read    [snd]
> > > > > > ffffffffa001a413 t snd_ctl_elem_write   [snd]
> > > > > > ffffffffa001a515 T snd_ctl_rename_id    [snd]
> > > > > > ffffffffa001a5b5 T snd_ctl_activate_id  [snd]
> > > > > > ffffffffa001a66e T snd_ctl_remove_id    [snd]
> > > > > > ffffffffa001a6ed T snd_ctl_add  [snd]
> > > > > > ffffffffa001a6ed u snd_ctl_add  [snd_hda_codec]
> > > > > > ffffffffa001a947 t snd_ctl_elem_add     [snd]
> > > > > > ffffffffa001abd3 t snd_ctl_elem_add_compat      [snd]
> > > > > > ffffffffa001ad37 t snd_ctl_elem_add_user        [snd]
> > > > > > ffffffffa001ada6 t snd_ctl_ioctl        [snd]
> > > > > >
> > > > > >
> > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001b
> > > > > > ffffffffa001b4c4 t snd_ctl_ioctl_compat [snd]
> > > > > > ffffffffa001b9ba T snd_ctl_new1 [snd]
> > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec]
> > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec_cirrus]
> > > > > > ffffffffa001bb30 T snd_pci_quirk_lookup [snd]
> > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_codec]
> > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_intel]
> > > > > > ffffffffa001bb93 T snd_verbose_printk   [snd]
> > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hda_codec]
> > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hda_intel]
> > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hwdep]
> > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_pcm]
> > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_timer]
> > > > > > ffffffffa001bc7b T release_and_free_resource    [snd]
> > > > > > ffffffffa001bcd4 t snd_device_register_all      [snd]
> > > > > > ffffffffa001bd76 T snd_device_register  [snd]
> > > > > > ffffffffa001bd76 u snd_device_register  [snd_pcm]
> > > > > > ffffffffa001be67 t snd_device_disconnect        [snd]
> > > > > > ffffffffa001bf5d t snd_device_disconnect_all    [snd]
> > > > > >
> > > > > >
> > > > > > hope that helps =)
> > > > >
> > > > > Maybe the patch below can give a better clue.
> > > > > This will spew stack traces when this error is triggered.  Don't be
> > > > > surprised.
> > > >
> > > > oki - new output =)
> > > >
> > > >
> > > > [16306.365597] snd: bad kfree (called from ffffffffa001b08f)
> > > > [16306.365604] Pid: 26533, comm: alsamixer Tainted: P        W 
> > > > 2.6.30.1 #2 [16306.365610] Call Trace:
> > > > [16306.365632]  [<ffffffffa001b08f>] ? snd_ctl_ioctl+0x2e5/0x71e
> > > > [snd] [16306.365645]  [<ffffffff802b8bf9>] ?
> > > > __inc_zone_state+0x20/0x9b [16306.365655]  [<ffffffff802cfffc>] ?
> > > > alloc_page_vma+0x197/0x1e1 [16306.365666]  [<ffffffff802afb63>] ?
> > > > __lru_cache_add+0x93/0xdd [16306.365676]  [<ffffffff802ea651>] ?
> > > > vfs_ioctl+0x35/0x97
> > > > [16306.365686]  [<ffffffff802eaae5>] ? do_vfs_ioctl+0x432/0x482
> > > > [16306.365696]  [<ffffffff806336bf>] ? _spin_lock_irqsave+0x28/0x5c
> > > > [16306.365705]  [<ffffffff80247e22>] ? do_page_fault+0x272/0x29e
> > > > [16306.365715]  [<ffffffff802eab82>] ? sys_ioctl+0x4d/0x81
> > > > [16306.365726]  [<ffffffff8022af2b>] ? system_call_fastpath+0x16/0x1b
> > >
> > > Try the very latest alsa-driver-unstable snapshot.
> > > This bug should have been fixed, also possibly with CS420x parser
> > > bug, too.
> > >
> > >
> > > Takashi
> >
> > so dmesg knows the following:
> >
> > [18042.848549] HDA Intel 0000:00:08.0: PCI INT A -> Link[LAZA] -> GSI 23
> > (level, low) -> IRQ 23 [18042.848623] HDA Intel 0000:00:08.0: setting
> > latency timer to 64 [18043.007568] ALSA
> > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> >a/hda_codec.c:3851: autoconfig: line_outs=1 (0xa/0x0/0x0/0x0/0x0)
> > [18043.007584] ALSA
> > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> >a/hda_codec.c:3855:    speaker_outs=1 (0xb/0x0/0x0/0x0/0x0) [18043.007596]
> > ALSA
> > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> >a/hda_codec.c:3859:    hp_outs=1 (0x9/0x0/0x0/0x0/0x0) [18043.007608] ALSA
> > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> >a/hda_codec.c:3860:    mono: mono_out=0x0 [18043.007618] ALSA
> > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> >a/hda_codec.c:3863:    dig-out=0x10/0x15 [18043.007628] ALSA
> > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> >a/hda_codec.c:3871:    inputs: mic=0xd, fmic=0x0, line=0xc, fline=0x0,
> > cd=0x0, aux=0x0
> > [18043.007642] ALSA
> > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> >a/hda_codec.c:3873:    dig-in=0x12 [18043.121187] ALSA
> > /home/nutz/tmp/alsa/alsa-driver-unstable/acore/control.c:337: control
> > 2:0:0:IEC958 Capture Switch:0 is already present [18043.121204]
> > hda_codec: cannot build controlsfor #0 (error -16)
> >
> >
> > and i don't have a mixer anymore ;)
>
> It's because your chip was uninitialized by BIOS or whatever, the
> another state you got sometimes.
>
> Now fixed in the driver to force to initialize pins.
> Try the latest tarball again.
>
>
> Takashi


TAKASHIIIIIIIIIIIII =)         
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

digital out is working... i tried the new snapshot (eventhough, as you said my 
subsystem is now again uninitialized)  and i got back the alsamixer-
capabilities;

i ran mplayer test.wav and started playing around with the mixer-controls. 

when i reached IEC958 and turned it on, my out-jack began to glow red =) so 
that works.   i rushed over to my dorm-partners speakersystem and plugged it 
in - voila that actually works! (i tried a DTS video with mplayer -vc hwdts )

that is SO cool =)

however as you might've figured out, analog out is not working, yet ;(   i 
tried the built-in speakers as well as the headphones (and of course all the 
devices from aplay -L again)

aplay -l      shows 2 devices now though:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 0: Cirrus Analog [Cirrus Analog]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 1: Cirrus Digital [Cirrus Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #1


should i try to reboot the machine to get back the other subsystem id? or is 
that irrelevant now?


thanks so much =)

andy



[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Mon, 6 Jul 2009 16:03:04 +0200,
Andreas Nüßlein wrote:
> 
> On Monday 06 July 2009 15:39:09 you wrote:
> > At Mon, 6 Jul 2009 14:59:09 +0200,
> >
> > Andreas Nüßlein wrote:
> > > On Monday 06 July 2009 14:44:56 you wrote:
> > > > At Mon, 6 Jul 2009 12:19:11 +0200,
> > > >
> > > > Andreas Nüßlein wrote:
> > > > > On Monday 06 July 2009 12:08:11 you wrote:
> > > > > > At Mon, 6 Jul 2009 11:45:07 +0200,
> > > > > >
> > > > > > Andreas Nüßlein wrote:
> > > > > > > [1  <text/plain; iso-8859-1 (quoted-printable)>]
> > > > > > >
> > > > > > > On Monday 06 July 2009 09:23:07 you wrote:
> > > > > > > > At Sun, 5 Jul 2009 12:30:52 +0200,
> > > > > > > >
> > > > > > > > > however i was able to reproduce the "bad kfree", by changing
> > > > > > > > > the volumes in alsamixer. it always gave me the same "called
> > > > > > > > > from ID" so i tried "while (true) do cat /proc/kallsyms |
> > > > > > > > > grep ffffffffa001b08b; done" and then changed the volume, but
> > > > > > > > > the grep never returned anything, dmesg of course got more
> > > > > > > > > and more of those kfree-errors.
> > > > > > > >
> > > > > > > > The address won't match exactly in /proc/kasllsyms.
> > > > > > > > But you can guess which function by address.  First sort
> > > > > > > > /proc/kallsyms then check the position that fits with the given
> > > > > > > > address.
> > > > > > > >
> > > > > > > >
> > > > > > > > Takashi
> > > > > > >
> > > > > > > well i'm not really sure _I_ can guess ;)    i guess it's either
> > > > > > > "t snd_ctl_ioctl        [snd]" or  "t snd_ctl_ioctl_compat
> > > > > > > [snd]".
> > > > > > >
> > > > > > > here are the greps, "snd: bad kfree (called from
> > > > > > > ffffffffa001b08b)" being the error:
> > > > > > >
> > > > > > >
> > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001a
> > > > > > > ffffffffa001a045 t snd_ctl_elem_info    [snd]
> > > > > > > ffffffffa001a17a t copy_ctl_value_from_user     [snd]
> > > > > > > ffffffffa001a34f t snd_ctl_elem_read    [snd]
> > > > > > > ffffffffa001a413 t snd_ctl_elem_write   [snd]
> > > > > > > ffffffffa001a515 T snd_ctl_rename_id    [snd]
> > > > > > > ffffffffa001a5b5 T snd_ctl_activate_id  [snd]
> > > > > > > ffffffffa001a66e T snd_ctl_remove_id    [snd]
> > > > > > > ffffffffa001a6ed T snd_ctl_add  [snd]
> > > > > > > ffffffffa001a6ed u snd_ctl_add  [snd_hda_codec]
> > > > > > > ffffffffa001a947 t snd_ctl_elem_add     [snd]
> > > > > > > ffffffffa001abd3 t snd_ctl_elem_add_compat      [snd]
> > > > > > > ffffffffa001ad37 t snd_ctl_elem_add_user        [snd]
> > > > > > > ffffffffa001ada6 t snd_ctl_ioctl        [snd]
> > > > > > >
> > > > > > >
> > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001b
> > > > > > > ffffffffa001b4c4 t snd_ctl_ioctl_compat [snd]
> > > > > > > ffffffffa001b9ba T snd_ctl_new1 [snd]
> > > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec]
> > > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec_cirrus]
> > > > > > > ffffffffa001bb30 T snd_pci_quirk_lookup [snd]
> > > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_codec]
> > > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_intel]
> > > > > > > ffffffffa001bb93 T snd_verbose_printk   [snd]
> > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hda_codec]
> > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hda_intel]
> > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hwdep]
> > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_pcm]
> > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_timer]
> > > > > > > ffffffffa001bc7b T release_and_free_resource    [snd]
> > > > > > > ffffffffa001bcd4 t snd_device_register_all      [snd]
> > > > > > > ffffffffa001bd76 T snd_device_register  [snd]
> > > > > > > ffffffffa001bd76 u snd_device_register  [snd_pcm]
> > > > > > > ffffffffa001be67 t snd_device_disconnect        [snd]
> > > > > > > ffffffffa001bf5d t snd_device_disconnect_all    [snd]
> > > > > > >
> > > > > > >
> > > > > > > hope that helps =)
> > > > > >
> > > > > > Maybe the patch below can give a better clue.
> > > > > > This will spew stack traces when this error is triggered.  Don't be
> > > > > > surprised.
> > > > >
> > > > > oki - new output =)
> > > > >
> > > > >
> > > > > [16306.365597] snd: bad kfree (called from ffffffffa001b08f)
> > > > > [16306.365604] Pid: 26533, comm: alsamixer Tainted: P        W 
> > > > > 2.6.30.1 #2 [16306.365610] Call Trace:
> > > > > [16306.365632]  [<ffffffffa001b08f>] ? snd_ctl_ioctl+0x2e5/0x71e
> > > > > [snd] [16306.365645]  [<ffffffff802b8bf9>] ?
> > > > > __inc_zone_state+0x20/0x9b [16306.365655]  [<ffffffff802cfffc>] ?
> > > > > alloc_page_vma+0x197/0x1e1 [16306.365666]  [<ffffffff802afb63>] ?
> > > > > __lru_cache_add+0x93/0xdd [16306.365676]  [<ffffffff802ea651>] ?
> > > > > vfs_ioctl+0x35/0x97
> > > > > [16306.365686]  [<ffffffff802eaae5>] ? do_vfs_ioctl+0x432/0x482
> > > > > [16306.365696]  [<ffffffff806336bf>] ? _spin_lock_irqsave+0x28/0x5c
> > > > > [16306.365705]  [<ffffffff80247e22>] ? do_page_fault+0x272/0x29e
> > > > > [16306.365715]  [<ffffffff802eab82>] ? sys_ioctl+0x4d/0x81
> > > > > [16306.365726]  [<ffffffff8022af2b>] ? system_call_fastpath+0x16/0x1b
> > > >
> > > > Try the very latest alsa-driver-unstable snapshot.
> > > > This bug should have been fixed, also possibly with CS420x parser
> > > > bug, too.
> > > >
> > > >
> > > > Takashi
> > >
> > > so dmesg knows the following:
> > >
> > > [18042.848549] HDA Intel 0000:00:08.0: PCI INT A -> Link[LAZA] -> GSI 23
> > > (level, low) -> IRQ 23 [18042.848623] HDA Intel 0000:00:08.0: setting
> > > latency timer to 64 [18043.007568] ALSA
> > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> > >a/hda_codec.c:3851: autoconfig: line_outs=1 (0xa/0x0/0x0/0x0/0x0)
> > > [18043.007584] ALSA
> > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> > >a/hda_codec.c:3855:    speaker_outs=1 (0xb/0x0/0x0/0x0/0x0) [18043.007596]
> > > ALSA
> > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> > >a/hda_codec.c:3859:    hp_outs=1 (0x9/0x0/0x0/0x0/0x0) [18043.007608] ALSA
> > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> > >a/hda_codec.c:3860:    mono: mono_out=0x0 [18043.007618] ALSA
> > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> > >a/hda_codec.c:3863:    dig-out=0x10/0x15 [18043.007628] ALSA
> > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> > >a/hda_codec.c:3871:    inputs: mic=0xd, fmic=0x0, line=0xc, fline=0x0,
> > > cd=0x0, aux=0x0
> > > [18043.007642] ALSA
> > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pci/hd
> > >a/hda_codec.c:3873:    dig-in=0x12 [18043.121187] ALSA
> > > /home/nutz/tmp/alsa/alsa-driver-unstable/acore/control.c:337: control
> > > 2:0:0:IEC958 Capture Switch:0 is already present [18043.121204]
> > > hda_codec: cannot build controlsfor #0 (error -16)
> > >
> > >
> > > and i don't have a mixer anymore ;)
> >
> > It's because your chip was uninitialized by BIOS or whatever, the
> > another state you got sometimes.
> >
> > Now fixed in the driver to force to initialize pins.
> > Try the latest tarball again.
> >
> >
> > Takashi
> 
> 
> TAKASHIIIIIIIIIIIII =)         
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> digital out is working... i tried the new snapshot (eventhough, as you said my 
> subsystem is now again uninitialized)  and i got back the alsamixer-
> capabilities;
> 
> i ran mplayer test.wav and started playing around with the mixer-controls. 
> 
> when i reached IEC958 and turned it on, my out-jack began to glow red =) so 
> that works.   i rushed over to my dorm-partners speakersystem and plugged it 
> in - voila that actually works! (i tried a DTS video with mplayer -vc hwdts )
> 
> that is SO cool =)
> 
> however as you might've figured out, analog out is not working, yet ;(   i 
> tried the built-in speakers as well as the headphones (and of course all the 

Hm, so you don't get any output although no errors with aplay?

Please give alsa-info.sh output with the latest driver to be sure.


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Mon, 6 Jul 2009 16:36:09 +0200,
Andreas Nüßlein wrote:
> 
> On Monday 06 July 2009 16:16:06 you wrote:
> > At Mon, 6 Jul 2009 16:03:04 +0200,
> >
> > Andreas Nüßlein wrote:
> > > On Monday 06 July 2009 15:39:09 you wrote:
> > > > At Mon, 6 Jul 2009 14:59:09 +0200,
> > > >
> > > > Andreas Nüßlein wrote:
> > > > > On Monday 06 July 2009 14:44:56 you wrote:
> > > > > > At Mon, 6 Jul 2009 12:19:11 +0200,
> > > > > >
> > > > > > Andreas Nüßlein wrote:
> > > > > > > On Monday 06 July 2009 12:08:11 you wrote:
> > > > > > > > At Mon, 6 Jul 2009 11:45:07 +0200,
> > > > > > > >
> > > > > > > > Andreas Nüßlein wrote:
> > > > > > > > > [1  <text/plain; iso-8859-1 (quoted-printable)>]
> > > > > > > > >
> > > > > > > > > On Monday 06 July 2009 09:23:07 you wrote:
> > > > > > > > > > At Sun, 5 Jul 2009 12:30:52 +0200,
> > > > > > > > > >
> > > > > > > > > > > however i was able to reproduce the "bad kfree", by
> > > > > > > > > > > changing the volumes in alsamixer. it always gave me the
> > > > > > > > > > > same "called from ID" so i tried "while (true) do cat
> > > > > > > > > > > /proc/kallsyms | grep ffffffffa001b08b; done" and then
> > > > > > > > > > > changed the volume, but the grep never returned anything,
> > > > > > > > > > > dmesg of course got more and more of those kfree-errors.
> > > > > > > > > >
> > > > > > > > > > The address won't match exactly in /proc/kasllsyms.
> > > > > > > > > > But you can guess which function by address.  First sort
> > > > > > > > > > /proc/kallsyms then check the position that fits with the
> > > > > > > > > > given address.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Takashi
> > > > > > > > >
> > > > > > > > > well i'm not really sure _I_ can guess ;)    i guess it's
> > > > > > > > > either "t snd_ctl_ioctl        [snd]" or  "t
> > > > > > > > > snd_ctl_ioctl_compat [snd]".
> > > > > > > > >
> > > > > > > > > here are the greps, "snd: bad kfree (called from
> > > > > > > > > ffffffffa001b08b)" being the error:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001a
> > > > > > > > > ffffffffa001a045 t snd_ctl_elem_info    [snd]
> > > > > > > > > ffffffffa001a17a t copy_ctl_value_from_user     [snd]
> > > > > > > > > ffffffffa001a34f t snd_ctl_elem_read    [snd]
> > > > > > > > > ffffffffa001a413 t snd_ctl_elem_write   [snd]
> > > > > > > > > ffffffffa001a515 T snd_ctl_rename_id    [snd]
> > > > > > > > > ffffffffa001a5b5 T snd_ctl_activate_id  [snd]
> > > > > > > > > ffffffffa001a66e T snd_ctl_remove_id    [snd]
> > > > > > > > > ffffffffa001a6ed T snd_ctl_add  [snd]
> > > > > > > > > ffffffffa001a6ed u snd_ctl_add  [snd_hda_codec]
> > > > > > > > > ffffffffa001a947 t snd_ctl_elem_add     [snd]
> > > > > > > > > ffffffffa001abd3 t snd_ctl_elem_add_compat      [snd]
> > > > > > > > > ffffffffa001ad37 t snd_ctl_elem_add_user        [snd]
> > > > > > > > > ffffffffa001ada6 t snd_ctl_ioctl        [snd]
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001b
> > > > > > > > > ffffffffa001b4c4 t snd_ctl_ioctl_compat [snd]
> > > > > > > > > ffffffffa001b9ba T snd_ctl_new1 [snd]
> > > > > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec]
> > > > > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec_cirrus]
> > > > > > > > > ffffffffa001bb30 T snd_pci_quirk_lookup [snd]
> > > > > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_codec]
> > > > > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_intel]
> > > > > > > > > ffffffffa001bb93 T snd_verbose_printk   [snd]
> > > > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hda_codec]
> > > > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hda_intel]
> > > > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hwdep]
> > > > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_pcm]
> > > > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_timer]
> > > > > > > > > ffffffffa001bc7b T release_and_free_resource    [snd]
> > > > > > > > > ffffffffa001bcd4 t snd_device_register_all      [snd]
> > > > > > > > > ffffffffa001bd76 T snd_device_register  [snd]
> > > > > > > > > ffffffffa001bd76 u snd_device_register  [snd_pcm]
> > > > > > > > > ffffffffa001be67 t snd_device_disconnect        [snd]
> > > > > > > > > ffffffffa001bf5d t snd_device_disconnect_all    [snd]
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > hope that helps =)
> > > > > > > >
> > > > > > > > Maybe the patch below can give a better clue.
> > > > > > > > This will spew stack traces when this error is triggered. 
> > > > > > > > Don't be surprised.
> > > > > > >
> > > > > > > oki - new output =)
> > > > > > >
> > > > > > >
> > > > > > > [16306.365597] snd: bad kfree (called from ffffffffa001b08f)
> > > > > > > [16306.365604] Pid: 26533, comm: alsamixer Tainted: P        W
> > > > > > > 2.6.30.1 #2 [16306.365610] Call Trace:
> > > > > > > [16306.365632]  [<ffffffffa001b08f>] ? snd_ctl_ioctl+0x2e5/0x71e
> > > > > > > [snd] [16306.365645]  [<ffffffff802b8bf9>] ?
> > > > > > > __inc_zone_state+0x20/0x9b [16306.365655]  [<ffffffff802cfffc>] ?
> > > > > > > alloc_page_vma+0x197/0x1e1 [16306.365666]  [<ffffffff802afb63>] ?
> > > > > > > __lru_cache_add+0x93/0xdd [16306.365676]  [<ffffffff802ea651>] ?
> > > > > > > vfs_ioctl+0x35/0x97
> > > > > > > [16306.365686]  [<ffffffff802eaae5>] ? do_vfs_ioctl+0x432/0x482
> > > > > > > [16306.365696]  [<ffffffff806336bf>] ?
> > > > > > > _spin_lock_irqsave+0x28/0x5c [16306.365705]  [<ffffffff80247e22>]
> > > > > > > ? do_page_fault+0x272/0x29e [16306.365715]  [<ffffffff802eab82>]
> > > > > > > ? sys_ioctl+0x4d/0x81 [16306.365726]  [<ffffffff8022af2b>] ?
> > > > > > > system_call_fastpath+0x16/0x1b
> > > > > >
> > > > > > Try the very latest alsa-driver-unstable snapshot.
> > > > > > This bug should have been fixed, also possibly with CS420x parser
> > > > > > bug, too.
> > > > > >
> > > > > >
> > > > > > Takashi
> > > > >
> > > > > so dmesg knows the following:
> > > > >
> > > > > [18042.848549] HDA Intel 0000:00:08.0: PCI INT A -> Link[LAZA] -> GSI
> > > > > 23 (level, low) -> IRQ 23 [18042.848623] HDA Intel 0000:00:08.0:
> > > > > setting latency timer to 64 [18043.007568] ALSA
> > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pc
> > > > >i/hd a/hda_codec.c:3851: autoconfig: line_outs=1 (0xa/0x0/0x0/0x0/0x0)
> > > > > [18043.007584] ALSA
> > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pc
> > > > >i/hd a/hda_codec.c:3855:    speaker_outs=1 (0xb/0x0/0x0/0x0/0x0)
> > > > > [18043.007596] ALSA
> > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pc
> > > > >i/hd a/hda_codec.c:3859:    hp_outs=1 (0x9/0x0/0x0/0x0/0x0)
> > > > > [18043.007608] ALSA
> > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pc
> > > > >i/hd a/hda_codec.c:3860:    mono: mono_out=0x0 [18043.007618] ALSA
> > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pc
> > > > >i/hd a/hda_codec.c:3863:    dig-out=0x10/0x15 [18043.007628] ALSA
> > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pc
> > > > >i/hd a/hda_codec.c:3871:    inputs: mic=0xd, fmic=0x0, line=0xc,
> > > > > fline=0x0, cd=0x0, aux=0x0
> > > > > [18043.007642] ALSA
> > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kernel/pc
> > > > >i/hd a/hda_codec.c:3873:    dig-in=0x12 [18043.121187] ALSA
> > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/acore/control.c:337: control
> > > > > 2:0:0:IEC958 Capture Switch:0 is already present [18043.121204]
> > > > > hda_codec: cannot build controlsfor #0 (error -16)
> > > > >
> > > > >
> > > > > and i don't have a mixer anymore ;)
> > > >
> > > > It's because your chip was uninitialized by BIOS or whatever, the
> > > > another state you got sometimes.
> > > >
> > > > Now fixed in the driver to force to initialize pins.
> > > > Try the latest tarball again.
> > > >
> > > >
> > > > Takashi
> > >
> > > TAKASHIIIIIIIIIIIII =)
> > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > >
> > > digital out is working... i tried the new snapshot (eventhough, as you
> > > said my subsystem is now again uninitialized)  and i got back the
> > > alsamixer- capabilities;
> > >
> > > i ran mplayer test.wav and started playing around with the
> > > mixer-controls.
> > >
> > > when i reached IEC958 and turned it on, my out-jack began to glow red =)
> > > so that works.   i rushed over to my dorm-partners speakersystem and
> > > plugged it in - voila that actually works! (i tried a DTS video with
> > > mplayer -vc hwdts )
> > >
> > > that is SO cool =)
> > >
> > > however as you might've figured out, analog out is not working, yet ;(  
> > > i tried the built-in speakers as well as the headphones (and of course
> > > all the
> >
> > Hm, so you don't get any output although no errors with aplay?
> >
> > Please give alsa-info.sh output with the latest driver to be sure.
> >
> >
> > Takashi
> 
> and here is the alsa-info with the "correct" subsystem id.
> 
> i also was able to get the wrong subsystem id again: i did 
> /etc/init.d/alsasound stop  && modprobe snd-hda-intel   - that changed it. 
> (i'll have a look into  init.d/alsasound to see if there are any clues)

Interesting.  So, resetting the controller alone can change the 
SSID.  It doesn't happen on other systems.


Could you try to apply the patch below on alsa-kernel directory with
-p2?  This will disable the additional COEF setups, which I blindly
copied from older cs4207 patch.


thanks,

Takashi

---
diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c
index b1fd183..fda83b2 100644
--- a/sound/pci/hda/patch_cirrus.c
+++ b/sound/pci/hda/patch_cirrus.c
@@ -933,7 +933,7 @@ static void init_input(struct hda_codec *codec)
 	change_cur_input(codec, spec->cur_input, 1);
 	if (spec->mic_detect)
 		cs_automic(codec);
-
+#if 0
 	coef = 0x000a; /* ADC1/2 - Digital and Analog Soft Ramp */
 	if (is_active_pin(codec, CS_DMIC2_PIN_NID))
 		coef |= 0x0500; /* DMIC2 enable 2 channels, disable GPIO1 */
@@ -943,6 +943,7 @@ static void init_input(struct hda_codec *codec)
 				 * IDX_SPDIF_CTL.
 				  */
 	cs_vendor_coef_set(codec, IDX_ADC_CFG, coef);
+#endif
 }
 
 static struct hda_verb cs_coef_init_verbs[] = {
@@ -980,10 +981,10 @@ static int cs_init(struct hda_codec *codec)
 {
 	struct cs_spec *spec = codec->spec;
 
-	snd_hda_sequence_write(codec, cs_coef_init_verbs);
+	/*snd_hda_sequence_write(codec, cs_coef_init_verbs);*/
 	init_output(codec);
 	init_input(codec);
-	init_digital(codec);
+	/*init_digital(codec);*/
 	return 0;
 }
 

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Mon, 6 Jul 2009 17:03:52 +0200,
Andreas Nüßlein wrote:
> 
> On Monday 06 July 2009 16:47:48 you wrote:
> > At Mon, 6 Jul 2009 16:36:09 +0200,
> >
> > Andreas Nüßlein wrote:
> > > On Monday 06 July 2009 16:16:06 you wrote:
> > > > At Mon, 6 Jul 2009 16:03:04 +0200,
> > > >
> > > > Andreas Nüßlein wrote:
> > > > > On Monday 06 July 2009 15:39:09 you wrote:
> > > > > > At Mon, 6 Jul 2009 14:59:09 +0200,
> > > > > >
> > > > > > Andreas Nüßlein wrote:
> > > > > > > On Monday 06 July 2009 14:44:56 you wrote:
> > > > > > > > At Mon, 6 Jul 2009 12:19:11 +0200,
> > > > > > > >
> > > > > > > > Andreas Nüßlein wrote:
> > > > > > > > > On Monday 06 July 2009 12:08:11 you wrote:
> > > > > > > > > > At Mon, 6 Jul 2009 11:45:07 +0200,
> > > > > > > > > >
> > > > > > > > > > Andreas Nüßlein wrote:
> > > > > > > > > > > [1  <text/plain; iso-8859-1 (quoted-printable)>]
> > > > > > > > > > >
> > > > > > > > > > > On Monday 06 July 2009 09:23:07 you wrote:
> > > > > > > > > > > > At Sun, 5 Jul 2009 12:30:52 +0200,
> > > > > > > > > > > >
> > > > > > > > > > > > > however i was able to reproduce the "bad kfree", by
> > > > > > > > > > > > > changing the volumes in alsamixer. it always gave me
> > > > > > > > > > > > > the same "called from ID" so i tried "while (true) do
> > > > > > > > > > > > > cat /proc/kallsyms | grep ffffffffa001b08b; done" and
> > > > > > > > > > > > > then changed the volume, but the grep never returned
> > > > > > > > > > > > > anything, dmesg of course got more and more of those
> > > > > > > > > > > > > kfree-errors.
> > > > > > > > > > > >
> > > > > > > > > > > > The address won't match exactly in /proc/kasllsyms.
> > > > > > > > > > > > But you can guess which function by address.  First
> > > > > > > > > > > > sort /proc/kallsyms then check the position that fits
> > > > > > > > > > > > with the given address.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Takashi
> > > > > > > > > > >
> > > > > > > > > > > well i'm not really sure _I_ can guess ;)    i guess it's
> > > > > > > > > > > either "t snd_ctl_ioctl        [snd]" or  "t
> > > > > > > > > > > snd_ctl_ioctl_compat [snd]".
> > > > > > > > > > >
> > > > > > > > > > > here are the greps, "snd: bad kfree (called from
> > > > > > > > > > > ffffffffa001b08b)" being the error:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001a
> > > > > > > > > > > ffffffffa001a045 t snd_ctl_elem_info    [snd]
> > > > > > > > > > > ffffffffa001a17a t copy_ctl_value_from_user     [snd]
> > > > > > > > > > > ffffffffa001a34f t snd_ctl_elem_read    [snd]
> > > > > > > > > > > ffffffffa001a413 t snd_ctl_elem_write   [snd]
> > > > > > > > > > > ffffffffa001a515 T snd_ctl_rename_id    [snd]
> > > > > > > > > > > ffffffffa001a5b5 T snd_ctl_activate_id  [snd]
> > > > > > > > > > > ffffffffa001a66e T snd_ctl_remove_id    [snd]
> > > > > > > > > > > ffffffffa001a6ed T snd_ctl_add  [snd]
> > > > > > > > > > > ffffffffa001a6ed u snd_ctl_add  [snd_hda_codec]
> > > > > > > > > > > ffffffffa001a947 t snd_ctl_elem_add     [snd]
> > > > > > > > > > > ffffffffa001abd3 t snd_ctl_elem_add_compat      [snd]
> > > > > > > > > > > ffffffffa001ad37 t snd_ctl_elem_add_user        [snd]
> > > > > > > > > > > ffffffffa001ada6 t snd_ctl_ioctl        [snd]
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001b
> > > > > > > > > > > ffffffffa001b4c4 t snd_ctl_ioctl_compat [snd]
> > > > > > > > > > > ffffffffa001b9ba T snd_ctl_new1 [snd]
> > > > > > > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec]
> > > > > > > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec_cirrus]
> > > > > > > > > > > ffffffffa001bb30 T snd_pci_quirk_lookup [snd]
> > > > > > > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_codec]
> > > > > > > > > > > ffffffffa001bb30 u snd_pci_quirk_lookup [snd_hda_intel]
> > > > > > > > > > > ffffffffa001bb93 T snd_verbose_printk   [snd]
> > > > > > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hda_codec]
> > > > > > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hda_intel]
> > > > > > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_hwdep]
> > > > > > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_pcm]
> > > > > > > > > > > ffffffffa001bb93 u snd_verbose_printk   [snd_timer]
> > > > > > > > > > > ffffffffa001bc7b T release_and_free_resource    [snd]
> > > > > > > > > > > ffffffffa001bcd4 t snd_device_register_all      [snd]
> > > > > > > > > > > ffffffffa001bd76 T snd_device_register  [snd]
> > > > > > > > > > > ffffffffa001bd76 u snd_device_register  [snd_pcm]
> > > > > > > > > > > ffffffffa001be67 t snd_device_disconnect        [snd]
> > > > > > > > > > > ffffffffa001bf5d t snd_device_disconnect_all    [snd]
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > hope that helps =)
> > > > > > > > > >
> > > > > > > > > > Maybe the patch below can give a better clue.
> > > > > > > > > > This will spew stack traces when this error is triggered.
> > > > > > > > > > Don't be surprised.
> > > > > > > > >
> > > > > > > > > oki - new output =)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > [16306.365597] snd: bad kfree (called from ffffffffa001b08f)
> > > > > > > > > [16306.365604] Pid: 26533, comm: alsamixer Tainted: P       
> > > > > > > > > W 2.6.30.1 #2 [16306.365610] Call Trace:
> > > > > > > > > [16306.365632]  [<ffffffffa001b08f>] ?
> > > > > > > > > snd_ctl_ioctl+0x2e5/0x71e [snd] [16306.365645] 
> > > > > > > > > [<ffffffff802b8bf9>] ?
> > > > > > > > > __inc_zone_state+0x20/0x9b [16306.365655] 
> > > > > > > > > [<ffffffff802cfffc>] ? alloc_page_vma+0x197/0x1e1
> > > > > > > > > [16306.365666]  [<ffffffff802afb63>] ?
> > > > > > > > > __lru_cache_add+0x93/0xdd [16306.365676] 
> > > > > > > > > [<ffffffff802ea651>] ? vfs_ioctl+0x35/0x97
> > > > > > > > > [16306.365686]  [<ffffffff802eaae5>] ?
> > > > > > > > > do_vfs_ioctl+0x432/0x482 [16306.365696]  [<ffffffff806336bf>]
> > > > > > > > > ?
> > > > > > > > > _spin_lock_irqsave+0x28/0x5c [16306.365705] 
> > > > > > > > > [<ffffffff80247e22>] ? do_page_fault+0x272/0x29e
> > > > > > > > > [16306.365715]  [<ffffffff802eab82>] ? sys_ioctl+0x4d/0x81
> > > > > > > > > [16306.365726]  [<ffffffff8022af2b>] ?
> > > > > > > > > system_call_fastpath+0x16/0x1b
> > > > > > > >
> > > > > > > > Try the very latest alsa-driver-unstable snapshot.
> > > > > > > > This bug should have been fixed, also possibly with CS420x
> > > > > > > > parser bug, too.
> > > > > > > >
> > > > > > > >
> > > > > > > > Takashi
> > > > > > >
> > > > > > > so dmesg knows the following:
> > > > > > >
> > > > > > > [18042.848549] HDA Intel 0000:00:08.0: PCI INT A -> Link[LAZA] ->
> > > > > > > GSI 23 (level, low) -> IRQ 23 [18042.848623] HDA Intel
> > > > > > > 0000:00:08.0: setting latency timer to 64 [18043.007568] ALSA
> > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne
> > > > > > >l/pc i/hd a/hda_codec.c:3851: autoconfig: line_outs=1
> > > > > > > (0xa/0x0/0x0/0x0/0x0) [18043.007584] ALSA
> > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne
> > > > > > >l/pc i/hd a/hda_codec.c:3855:    speaker_outs=1
> > > > > > > (0xb/0x0/0x0/0x0/0x0) [18043.007596] ALSA
> > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne
> > > > > > >l/pc i/hd a/hda_codec.c:3859:    hp_outs=1 (0x9/0x0/0x0/0x0/0x0)
> > > > > > > [18043.007608] ALSA
> > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne
> > > > > > >l/pc i/hd a/hda_codec.c:3860:    mono: mono_out=0x0 [18043.007618]
> > > > > > > ALSA
> > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne
> > > > > > >l/pc i/hd a/hda_codec.c:3863:    dig-out=0x10/0x15 [18043.007628]
> > > > > > > ALSA
> > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne
> > > > > > >l/pc i/hd a/hda_codec.c:3871:    inputs: mic=0xd, fmic=0x0,
> > > > > > > line=0xc, fline=0x0, cd=0x0, aux=0x0
> > > > > > > [18043.007642] ALSA
> > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-kerne
> > > > > > >l/pc i/hd a/hda_codec.c:3873:    dig-in=0x12 [18043.121187] ALSA
> > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/acore/control.c:337:
> > > > > > > control 2:0:0:IEC958 Capture Switch:0 is already present
> > > > > > > [18043.121204] hda_codec: cannot build controlsfor #0 (error -16)
> > > > > > >
> > > > > > >
> > > > > > > and i don't have a mixer anymore ;)
> > > > > >
> > > > > > It's because your chip was uninitialized by BIOS or whatever, the
> > > > > > another state you got sometimes.
> > > > > >
> > > > > > Now fixed in the driver to force to initialize pins.
> > > > > > Try the latest tarball again.
> > > > > >
> > > > > >
> > > > > > Takashi
> > > > >
> > > > > TAKASHIIIIIIIIIIIII =)
> > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > > > >
> > > > > digital out is working... i tried the new snapshot (eventhough, as
> > > > > you said my subsystem is now again uninitialized)  and i got back the
> > > > > alsamixer- capabilities;
> > > > >
> > > > > i ran mplayer test.wav and started playing around with the
> > > > > mixer-controls.
> > > > >
> > > > > when i reached IEC958 and turned it on, my out-jack began to glow red
> > > > > =) so that works.   i rushed over to my dorm-partners speakersystem
> > > > > and plugged it in - voila that actually works! (i tried a DTS video
> > > > > with mplayer -vc hwdts )
> > > > >
> > > > > that is SO cool =)
> > > > >
> > > > > however as you might've figured out, analog out is not working, yet
> > > > > ;( i tried the built-in speakers as well as the headphones (and of
> > > > > course all the
> > > >
> > > > Hm, so you don't get any output although no errors with aplay?
> > > >
> > > > Please give alsa-info.sh output with the latest driver to be sure.
> > > >
> > > >
> > > > Takashi
> > >
> > > and here is the alsa-info with the "correct" subsystem id.
> > >
> > > i also was able to get the wrong subsystem id again: i did
> > > /etc/init.d/alsasound stop  && modprobe snd-hda-intel   - that changed
> > > it. (i'll have a look into  init.d/alsasound to see if there are any
> > > clues)
> >
> > Interesting.  So, resetting the controller alone can change the
> > SSID.  It doesn't happen on other systems.
> >
> >
> > Could you try to apply the patch below on alsa-kernel directory with
> > -p2?  This will disable the additional COEF setups, which I blindly
> > copied from older cs4207 patch.
> >
> >
> > thanks,
> >
> > Takashi
> >
> > ---
> > diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c
> > index b1fd183..fda83b2 100644
> > --- a/sound/pci/hda/patch_cirrus.c
> > +++ b/sound/pci/hda/patch_cirrus.c
> > @@ -933,7 +933,7 @@ static void init_input(struct hda_codec *codec)
> >  	change_cur_input(codec, spec->cur_input, 1);
> >  	if (spec->mic_detect)
> >  		cs_automic(codec);
> > -
> > +#if 0
> >  	coef = 0x000a; /* ADC1/2 - Digital and Analog Soft Ramp */
> >  	if (is_active_pin(codec, CS_DMIC2_PIN_NID))
> >  		coef |= 0x0500; /* DMIC2 enable 2 channels, disable GPIO1 */
> > @@ -943,6 +943,7 @@ static void init_input(struct hda_codec *codec)
> >  				 * IDX_SPDIF_CTL.
> >  				  */
> >  	cs_vendor_coef_set(codec, IDX_ADC_CFG, coef);
> > +#endif
> >  }
> >
> >  static struct hda_verb cs_coef_init_verbs[] = {
> > @@ -980,10 +981,10 @@ static int cs_init(struct hda_codec *codec)
> >  {
> >  	struct cs_spec *spec = codec->spec;
> >
> > -	snd_hda_sequence_write(codec, cs_coef_init_verbs);
> > +	/*snd_hda_sequence_write(codec, cs_coef_init_verbs);*/
> >  	init_output(codec);
> >  	init_input(codec);
> > -	init_digital(codec);
> > +	/*init_digital(codec);*/
> >  	return 0;
> >  }
> 
> 
> wow okay...
> so aplay test.wav  didn't give me any sound, but when i tried to stop it (Ctrl-C) i couldn't and i had to kill it from another term, which resulted in this:

When you run like below
	% aplay -Dplughw -vvv somefile.wav
does it proceed?

If not, it means that the DMA got stuck somewhere.  If it goes,
then the problem is in another place.


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Mon, 6 Jul 2009 17:23:17 +0200,
Andreas Nüßlein wrote:
> 
> On Monday 06 July 2009 17:13:29 you wrote:
> > At Mon, 6 Jul 2009 17:03:52 +0200,
> >
> > Andreas Nüßlein wrote:
> > > On Monday 06 July 2009 16:47:48 you wrote:
> > > > At Mon, 6 Jul 2009 16:36:09 +0200,
> > > >
> > > > Andreas Nüßlein wrote:
> > > > > On Monday 06 July 2009 16:16:06 you wrote:
> > > > > > At Mon, 6 Jul 2009 16:03:04 +0200,
> > > > > >
> > > > > > Andreas Nüßlein wrote:
> > > > > > > On Monday 06 July 2009 15:39:09 you wrote:
> > > > > > > > At Mon, 6 Jul 2009 14:59:09 +0200,
> > > > > > > >
> > > > > > > > Andreas Nüßlein wrote:
> > > > > > > > > On Monday 06 July 2009 14:44:56 you wrote:
> > > > > > > > > > At Mon, 6 Jul 2009 12:19:11 +0200,
> > > > > > > > > >
> > > > > > > > > > Andreas Nüßlein wrote:
> > > > > > > > > > > On Monday 06 July 2009 12:08:11 you wrote:
> > > > > > > > > > > > At Mon, 6 Jul 2009 11:45:07 +0200,
> > > > > > > > > > > >
> > > > > > > > > > > > Andreas Nüßlein wrote:
> > > > > > > > > > > > > [1  <text/plain; iso-8859-1 (quoted-printable)>]
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Monday 06 July 2009 09:23:07 you wrote:
> > > > > > > > > > > > > > At Sun, 5 Jul 2009 12:30:52 +0200,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > however i was able to reproduce the "bad kfree",
> > > > > > > > > > > > > > > by changing the volumes in alsamixer. it always
> > > > > > > > > > > > > > > gave me the same "called from ID" so i tried
> > > > > > > > > > > > > > > "while (true) do cat /proc/kallsyms | grep
> > > > > > > > > > > > > > > ffffffffa001b08b; done" and then changed the
> > > > > > > > > > > > > > > volume, but the grep never returned anything,
> > > > > > > > > > > > > > > dmesg of course got more and more of those
> > > > > > > > > > > > > > > kfree-errors.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The address won't match exactly in /proc/kasllsyms.
> > > > > > > > > > > > > > But you can guess which function by address.  First
> > > > > > > > > > > > > > sort /proc/kallsyms then check the position that
> > > > > > > > > > > > > > fits with the given address.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Takashi
> > > > > > > > > > > > >
> > > > > > > > > > > > > well i'm not really sure _I_ can guess ;)    i guess
> > > > > > > > > > > > > it's either "t snd_ctl_ioctl        [snd]" or  "t
> > > > > > > > > > > > > snd_ctl_ioctl_compat [snd]".
> > > > > > > > > > > > >
> > > > > > > > > > > > > here are the greps, "snd: bad kfree (called from
> > > > > > > > > > > > > ffffffffa001b08b)" being the error:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001a
> > > > > > > > > > > > > ffffffffa001a045 t snd_ctl_elem_info    [snd]
> > > > > > > > > > > > > ffffffffa001a17a t copy_ctl_value_from_user     [snd]
> > > > > > > > > > > > > ffffffffa001a34f t snd_ctl_elem_read    [snd]
> > > > > > > > > > > > > ffffffffa001a413 t snd_ctl_elem_write   [snd]
> > > > > > > > > > > > > ffffffffa001a515 T snd_ctl_rename_id    [snd]
> > > > > > > > > > > > > ffffffffa001a5b5 T snd_ctl_activate_id  [snd]
> > > > > > > > > > > > > ffffffffa001a66e T snd_ctl_remove_id    [snd]
> > > > > > > > > > > > > ffffffffa001a6ed T snd_ctl_add  [snd]
> > > > > > > > > > > > > ffffffffa001a6ed u snd_ctl_add  [snd_hda_codec]
> > > > > > > > > > > > > ffffffffa001a947 t snd_ctl_elem_add     [snd]
> > > > > > > > > > > > > ffffffffa001abd3 t snd_ctl_elem_add_compat      [snd]
> > > > > > > > > > > > > ffffffffa001ad37 t snd_ctl_elem_add_user        [snd]
> > > > > > > > > > > > > ffffffffa001ada6 t snd_ctl_ioctl        [snd]
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > $ cat /proc/kallsyms | sort | grep ffffffffa001b
> > > > > > > > > > > > > ffffffffa001b4c4 t snd_ctl_ioctl_compat [snd]
> > > > > > > > > > > > > ffffffffa001b9ba T snd_ctl_new1 [snd]
> > > > > > > > > > > > > ffffffffa001b9ba u snd_ctl_new1 [snd_hda_codec]
> > > > > > > > > > > > > ffffffffa001b9ba u snd_ctl_new1
> > > > > > > > > > > > > [snd_hda_codec_cirrus] ffffffffa001bb30 T
> > > > > > > > > > > > > snd_pci_quirk_lookup [snd] ffffffffa001bb30 u
> > > > > > > > > > > > > snd_pci_quirk_lookup [snd_hda_codec] ffffffffa001bb30
> > > > > > > > > > > > > u snd_pci_quirk_lookup [snd_hda_intel]
> > > > > > > > > > > > > ffffffffa001bb93 T snd_verbose_printk   [snd]
> > > > > > > > > > > > > ffffffffa001bb93 u snd_verbose_printk  
> > > > > > > > > > > > > [snd_hda_codec] ffffffffa001bb93 u snd_verbose_printk
> > > > > > > > > > > > >   [snd_hda_intel] ffffffffa001bb93 u
> > > > > > > > > > > > > snd_verbose_printk   [snd_hwdep] ffffffffa001bb93 u
> > > > > > > > > > > > > snd_verbose_printk   [snd_pcm] ffffffffa001bb93 u
> > > > > > > > > > > > > snd_verbose_printk   [snd_timer] ffffffffa001bc7b T
> > > > > > > > > > > > > release_and_free_resource    [snd] ffffffffa001bcd4 t
> > > > > > > > > > > > > snd_device_register_all      [snd] ffffffffa001bd76 T
> > > > > > > > > > > > > snd_device_register  [snd] ffffffffa001bd76 u
> > > > > > > > > > > > > snd_device_register  [snd_pcm] ffffffffa001be67 t
> > > > > > > > > > > > > snd_device_disconnect        [snd] ffffffffa001bf5d t
> > > > > > > > > > > > > snd_device_disconnect_all    [snd]
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > hope that helps =)
> > > > > > > > > > > >
> > > > > > > > > > > > Maybe the patch below can give a better clue.
> > > > > > > > > > > > This will spew stack traces when this error is
> > > > > > > > > > > > triggered. Don't be surprised.
> > > > > > > > > > >
> > > > > > > > > > > oki - new output =)
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > [16306.365597] snd: bad kfree (called from
> > > > > > > > > > > ffffffffa001b08f) [16306.365604] Pid: 26533, comm:
> > > > > > > > > > > alsamixer Tainted: P W 2.6.30.1 #2 [16306.365610] Call
> > > > > > > > > > > Trace:
> > > > > > > > > > > [16306.365632]  [<ffffffffa001b08f>] ?
> > > > > > > > > > > snd_ctl_ioctl+0x2e5/0x71e [snd] [16306.365645]
> > > > > > > > > > > [<ffffffff802b8bf9>] ?
> > > > > > > > > > > __inc_zone_state+0x20/0x9b [16306.365655]
> > > > > > > > > > > [<ffffffff802cfffc>] ? alloc_page_vma+0x197/0x1e1
> > > > > > > > > > > [16306.365666]  [<ffffffff802afb63>] ?
> > > > > > > > > > > __lru_cache_add+0x93/0xdd [16306.365676]
> > > > > > > > > > > [<ffffffff802ea651>] ? vfs_ioctl+0x35/0x97
> > > > > > > > > > > [16306.365686]  [<ffffffff802eaae5>] ?
> > > > > > > > > > > do_vfs_ioctl+0x432/0x482 [16306.365696] 
> > > > > > > > > > > [<ffffffff806336bf>] ?
> > > > > > > > > > > _spin_lock_irqsave+0x28/0x5c [16306.365705]
> > > > > > > > > > > [<ffffffff80247e22>] ? do_page_fault+0x272/0x29e
> > > > > > > > > > > [16306.365715]  [<ffffffff802eab82>] ?
> > > > > > > > > > > sys_ioctl+0x4d/0x81 [16306.365726]  [<ffffffff8022af2b>]
> > > > > > > > > > > ?
> > > > > > > > > > > system_call_fastpath+0x16/0x1b
> > > > > > > > > >
> > > > > > > > > > Try the very latest alsa-driver-unstable snapshot.
> > > > > > > > > > This bug should have been fixed, also possibly with CS420x
> > > > > > > > > > parser bug, too.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Takashi
> > > > > > > > >
> > > > > > > > > so dmesg knows the following:
> > > > > > > > >
> > > > > > > > > [18042.848549] HDA Intel 0000:00:08.0: PCI INT A ->
> > > > > > > > > Link[LAZA] -> GSI 23 (level, low) -> IRQ 23 [18042.848623]
> > > > > > > > > HDA Intel 0000:00:08.0: setting latency timer to 64
> > > > > > > > > [18043.007568] ALSA
> > > > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-k
> > > > > > > > >erne l/pc i/hd a/hda_codec.c:3851: autoconfig: line_outs=1
> > > > > > > > > (0xa/0x0/0x0/0x0/0x0) [18043.007584] ALSA
> > > > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-k
> > > > > > > > >erne l/pc i/hd a/hda_codec.c:3855:    speaker_outs=1
> > > > > > > > > (0xb/0x0/0x0/0x0/0x0) [18043.007596] ALSA
> > > > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-k
> > > > > > > > >erne l/pc i/hd a/hda_codec.c:3859:    hp_outs=1
> > > > > > > > > (0x9/0x0/0x0/0x0/0x0) [18043.007608] ALSA
> > > > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-k
> > > > > > > > >erne l/pc i/hd a/hda_codec.c:3860:    mono: mono_out=0x0
> > > > > > > > > [18043.007618] ALSA
> > > > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-k
> > > > > > > > >erne l/pc i/hd a/hda_codec.c:3863:    dig-out=0x10/0x15
> > > > > > > > > [18043.007628] ALSA
> > > > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-k
> > > > > > > > >erne l/pc i/hd a/hda_codec.c:3871:    inputs: mic=0xd,
> > > > > > > > > fmic=0x0, line=0xc, fline=0x0, cd=0x0, aux=0x0
> > > > > > > > > [18043.007642] ALSA
> > > > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/pci/hda/../../alsa-k
> > > > > > > > >erne l/pc i/hd a/hda_codec.c:3873:    dig-in=0x12
> > > > > > > > > [18043.121187] ALSA
> > > > > > > > > /home/nutz/tmp/alsa/alsa-driver-unstable/acore/control.c:337:
> > > > > > > > > control 2:0:0:IEC958 Capture Switch:0 is already present
> > > > > > > > > [18043.121204] hda_codec: cannot build controlsfor #0 (error
> > > > > > > > > -16)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > and i don't have a mixer anymore ;)
> > > > > > > >
> > > > > > > > It's because your chip was uninitialized by BIOS or whatever,
> > > > > > > > the another state you got sometimes.
> > > > > > > >
> > > > > > > > Now fixed in the driver to force to initialize pins.
> > > > > > > > Try the latest tarball again.
> > > > > > > >
> > > > > > > >
> > > > > > > > Takashi
> > > > > > >
> > > > > > > TAKASHIIIIIIIIIIIII =)
> > > > > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > > > > > >
> > > > > > > digital out is working... i tried the new snapshot (eventhough,
> > > > > > > as you said my subsystem is now again uninitialized)  and i got
> > > > > > > back the alsamixer- capabilities;
> > > > > > >
> > > > > > > i ran mplayer test.wav and started playing around with the
> > > > > > > mixer-controls.
> > > > > > >
> > > > > > > when i reached IEC958 and turned it on, my out-jack began to glow
> > > > > > > red =) so that works.   i rushed over to my dorm-partners
> > > > > > > speakersystem and plugged it in - voila that actually works! (i
> > > > > > > tried a DTS video with mplayer -vc hwdts )
> > > > > > >
> > > > > > > that is SO cool =)
> > > > > > >
> > > > > > > however as you might've figured out, analog out is not working,
> > > > > > > yet ;( i tried the built-in speakers as well as the headphones
> > > > > > > (and of course all the
> > > > > >
> > > > > > Hm, so you don't get any output although no errors with aplay?
> > > > > >
> > > > > > Please give alsa-info.sh output with the latest driver to be sure.
> > > > > >
> > > > > >
> > > > > > Takashi
> > > > >
> > > > > and here is the alsa-info with the "correct" subsystem id.
> > > > >
> > > > > i also was able to get the wrong subsystem id again: i did
> > > > > /etc/init.d/alsasound stop  && modprobe snd-hda-intel   - that
> > > > > changed it. (i'll have a look into  init.d/alsasound to see if there
> > > > > are any clues)
> > > >
> > > > Interesting.  So, resetting the controller alone can change the
> > > > SSID.  It doesn't happen on other systems.
> > > >
> > > >
> > > > Could you try to apply the patch below on alsa-kernel directory with
> > > > -p2?  This will disable the additional COEF setups, which I blindly
> > > > copied from older cs4207 patch.
> > > >
> > > >
> > > > thanks,
> > > >
> > > > Takashi
> > > >
> > > > ---
> > > > diff --git a/sound/pci/hda/patch_cirrus.c
> > > > b/sound/pci/hda/patch_cirrus.c index b1fd183..fda83b2 100644
> > > > --- a/sound/pci/hda/patch_cirrus.c
> > > > +++ b/sound/pci/hda/patch_cirrus.c
> > > > @@ -933,7 +933,7 @@ static void init_input(struct hda_codec *codec)
> > > >  	change_cur_input(codec, spec->cur_input, 1);
> > > >  	if (spec->mic_detect)
> > > >  		cs_automic(codec);
> > > > -
> > > > +#if 0
> > > >  	coef = 0x000a; /* ADC1/2 - Digital and Analog Soft Ramp */
> > > >  	if (is_active_pin(codec, CS_DMIC2_PIN_NID))
> > > >  		coef |= 0x0500; /* DMIC2 enable 2 channels, disable GPIO1 */
> > > > @@ -943,6 +943,7 @@ static void init_input(struct hda_codec *codec)
> > > >  				 * IDX_SPDIF_CTL.
> > > >  				  */
> > > >  	cs_vendor_coef_set(codec, IDX_ADC_CFG, coef);
> > > > +#endif
> > > >  }
> > > >
> > > >  static struct hda_verb cs_coef_init_verbs[] = {
> > > > @@ -980,10 +981,10 @@ static int cs_init(struct hda_codec *codec)
> > > >  {
> > > >  	struct cs_spec *spec = codec->spec;
> > > >
> > > > -	snd_hda_sequence_write(codec, cs_coef_init_verbs);
> > > > +	/*snd_hda_sequence_write(codec, cs_coef_init_verbs);*/
> > > >  	init_output(codec);
> > > >  	init_input(codec);
> > > > -	init_digital(codec);
> > > > +	/*init_digital(codec);*/
> > > >  	return 0;
> > > >  }
> > >
> > > wow okay...
> > > so aplay test.wav  didn't give me any sound, but when i tried to stop it
> > > (Ctrl-C) i couldn't and i had to kill it from another term, which
> > > resulted in this:
> >
> > When you run like below
> > 	% aplay -Dplughw -vvv somefile.wav
> > does it proceed?
> >
> > If not, it means that the DMA got stuck somewhere.  If it goes,
> > then the problem is in another place.
> >
> >
> > Takashi
> 
> 
> $ aplay -Dplughw -vvv media/test.wav
> Playing WAVE 'media/test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, 
> Stereo
> Plug PCM: Hardware PCM card 0 'HDA NVidia' device 0 subdevice 0
> Its setup is:
>   stream       : PLAYBACK
>   access       : RW_INTERLEAVED
>   format       : S16_LE
>   subformat    : STD
>   channels     : 2
>   rate         : 44100
>   exact rate   : 44100 (44100/1)
>   msbits       : 16
>   buffer_size  : 16384
>   period_size  : 4096
>   period_time  : 92879
>   tstamp_mode  : NONE
>   period_step  : 1
>   avail_min    : 4096
>   period_event : 0
>   start_threshold  : 16384
>   stop_threshold   : 16384
>   silence_threshold: 0
>   silence_size : 0
>   boundary     : 4611686018427387904
>   appl_ptr     : 0
>   hw_ptr       : 0
> Max peak (8192 samples): 0x0000003f #                    0%
> Max peak (8192 samples): 0x0000004a #                    0%
> 
> ...
> 
> 
> yeah this works every time. 
> 
> so is it okay right now when the subsystem ID is the "uninitialized" one? or 
> should i restart the machine so i get the "correct one" back?

The missing pin configuration initialization was already fixed by
the driver overriding it after checking PCI SSID (which is different
from the codec SSID).  So, this should be no problem.

However, the reason why the analog output doesn't work might be
different from that.  There might be something else missing, but I
don't know.


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Mon, 6 Jul 2009 17:53:46 +0200,
Andreas Nüßlein wrote:
> 
> > The missing pin configuration initialization was already fixed by
> > the driver overriding it after checking PCI SSID (which is different
> > from the codec SSID).  So, this should be no problem.
> >
> > However, the reason why the analog output doesn't work might be
> > different from that.  There might be something else missing, but I
> > don't know.
> >
> >
> > Takashi
> 
> oh =(
> 
> 
> hmm.. anything i can do?  would it help if i tried changing values randomly 
> with hda-analyzer.py?

Well, did the driver without my change work more or less with
the analog audio, or have you never gotten the analog output?
You can use the generic parser (i.e. the state without cirrus patch)
by passing model=generic option to snd-hda-intel.


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Sean Burke]

Scríobh Takashi Iwai:
> At Mon, 6 Jul 2009 17:53:46 +0200,
> Andreas Nüßlein wrote:
>   
>>> The missing pin configuration initialization was already fixed by
>>> the driver overriding it after checking PCI SSID (which is different
>>> from the codec SSID).  So, this should be no problem.
>>>
>>> However, the reason why the analog output doesn't work might be
>>> different from that.  There might be something else missing, but I
>>> don't know.
>>>
>>>
>>> Takashi
>>>       
>> oh =(
>>
>>
>> hmm.. anything i can do?  would it help if i tried changing values randomly 
>> with hda-analyzer.py?
>>     
>
> Well, did the driver without my change work more or less with
> the analog audio, or have you never gotten the analog output?
> You can use the generic parser (i.e. the state without cirrus patch)
> by passing model=generic option to snd-hda-intel.
>   
For my part, nothing worked with the generic driver. I can't confirm
digital out, but I can confirm that the kfree error is gone. What
options are open for figuring out what remains?


Sean

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Mon, 06 Jul 2009 11:16:35 -0600,
Sean Burke wrote:
> 
> Scríobh Takashi Iwai:
> > At Mon, 6 Jul 2009 17:53:46 +0200,
> > Andreas Nüßlein wrote:
> >   
> >>> The missing pin configuration initialization was already fixed by
> >>> the driver overriding it after checking PCI SSID (which is different
> >>> from the codec SSID).  So, this should be no problem.
> >>>
> >>> However, the reason why the analog output doesn't work might be
> >>> different from that.  There might be something else missing, but I
> >>> don't know.
> >>>
> >>>
> >>> Takashi
> >>>       
> >> oh =(
> >>
> >>
> >> hmm.. anything i can do?  would it help if i tried changing values randomly 
> >> with hda-analyzer.py?
> >>     
> >
> > Well, did the driver without my change work more or less with
> > the analog audio, or have you never gotten the analog output?
> > You can use the generic parser (i.e. the state without cirrus patch)
> > by passing model=generic option to snd-hda-intel.
> >   
> For my part, nothing worked with the generic driver. I can't confirm
> digital out, but I can confirm that the kfree error is gone. What
> options are open for figuring out what remains?

Easy things to test are GPIO bits.  Run hda-verb like

	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
or
	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f

etc.  CS4206 seems to have 4 GPIO lines, and each bit (0-3)
corresponds to each GPIO.  In many case, GPIO0 or GPIO1 corresponds to
the amplifier (EAPD) bit.
Define the GPIO direction of each GPIO bit by SET_GPIO_DIR, and
turn on/off the GPIO bits by SET_GPIO_DATA.  Running
	hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0
will show the current GPIO data bits.  Or you can check it in codec#*
proc file.


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Mon, 6 Jul 2009 22:14:56 +0200,
Andreas Nüßlein wrote:
> 
> On Monday 06 July 2009 21:26:18 you wrote:
> > At Mon, 06 Jul 2009 11:16:35 -0600,
> >
> > Sean Burke wrote:
> > > Scríobh Takashi Iwai:
> > > > At Mon, 6 Jul 2009 17:53:46 +0200,
> > > >
> > > > Andreas Nüßlein wrote:
> > > >>> The missing pin configuration initialization was already fixed by
> > > >>> the driver overriding it after checking PCI SSID (which is different
> > > >>> from the codec SSID).  So, this should be no problem.
> > > >>>
> > > >>> However, the reason why the analog output doesn't work might be
> > > >>> different from that.  There might be something else missing, but I
> > > >>> don't know.
> > > >>>
> > > >>>
> > > >>> Takashi
> > > >>
> > > >> oh =(
> > > >>
> > > >>
> > > >> hmm.. anything i can do?  would it help if i tried changing values
> > > >> randomly with hda-analyzer.py?
> > > >
> > > > Well, did the driver without my change work more or less with
> > > > the analog audio, or have you never gotten the analog output?
> > > > You can use the generic parser (i.e. the state without cirrus patch)
> > > > by passing model=generic option to snd-hda-intel.
> > >
> > > For my part, nothing worked with the generic driver. I can't confirm
> > > digital out, but I can confirm that the kfree error is gone. What
> > > options are open for figuring out what remains?
> >
> > Easy things to test are GPIO bits.  Run hda-verb like
> >
> > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > or
> > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> >
> > etc.  CS4206 seems to have 4 GPIO lines, and each bit (0-3)
> > corresponds to each GPIO.  In many case, GPIO0 or GPIO1 corresponds to
> > the amplifier (EAPD) bit.
> > Define the GPIO direction of each GPIO bit by SET_GPIO_DIR, and
> > turn on/off the GPIO bits by SET_GPIO_DATA.  Running
> > 	hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0
> > will show the current GPIO data bits.  Or you can check it in codec#*
> > proc file.
> >
> >
> > Takashi
> 
> w000000000000000000000000000000000t! =)
> 
> takashi, thank you _so_ much!
> 
> after running all 4 of those:
> > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > or
> > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> >
> 
> i suddendly had sound!! :D :D :D :D :D :D :D 
> only via speakers  though - there is no sound via headphones right now. 
> 
> mixer channels: 
> - Master (with Mutebutton), PCM and Front (also with Mute) all work =)
> - i don't know what surround would do (or it's extra switch)
> - headphones-volumes and mute button don't affect the speakers, which is good 
> =)
> 
> 
> is there a way to reset what i did with hda-verb, so that i can figure out 
> which combination it was exactly?

You can just change the value 0x0f to a different value.
At least, you can try commands like
 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04
 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
and check the speaker output at each time.
Also, check the GPIO direction,
 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01
 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02
 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
	...

Regarding the headphone: is the speaker muted when you plug in the
headphone?  If not, it's likely an issue of the jack detection.  If
the speaker is muted but no headphone output, it's a missing
initialization (or wrong GPIO setup).


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Tue, 07 Jul 2009 00:24:51 -0600,
Sean Burke wrote:
> 
> Scríobh Takashi Iwai:
> > At Mon, 6 Jul 2009 22:14:56 +0200,
> > Andreas Nüßlein wrote:
> >   
> >> On Monday 06 July 2009 21:26:18 you wrote:
> >>     
> >>> At Mon, 06 Jul 2009 11:16:35 -0600,
> >>>       
> >>> Easy things to test are GPIO bits.  Run hda-verb like
> >>>
> >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> >>> or
> >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> >>>
> >>> etc.  CS4206 seems to have 4 GPIO lines, and each bit (0-3)
> >>> corresponds to each GPIO.  In many case, GPIO0 or GPIO1 corresponds to
> >>> the amplifier (EAPD) bit.
> >>> Define the GPIO direction of each GPIO bit by SET_GPIO_DIR, and
> >>> turn on/off the GPIO bits by SET_GPIO_DATA.  Running
> >>> 	hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0
> >>> will show the current GPIO data bits.  Or you can check it in codec#*
> >>> proc file.
> >>>
> >>>
> >>> Takashi
> >>>       
> >> w000000000000000000000000000000000t! =)
> >>
> >> takashi, thank you _so_ much!
> >>
> >> after running all 4 of those:
> >>     
> >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> >>> or
> >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> >>>
> >>>       
> >> i suddendly had sound!! :D :D :D :D :D :D :D 
> >> only via speakers  though - there is no sound via headphones right now. 
> >>
> >> mixer channels: 
> >> - Master (with Mutebutton), PCM and Front (also with Mute) all work =)
> >> - i don't know what surround would do (or it's extra switch)
> >> - headphones-volumes and mute button don't affect the speakers, which is good 
> >> =)
> >>
> >>
> >> is there a way to reset what i did with hda-verb, so that i can figure out 
> >> which combination it was exactly?
> >>     
> >
> > You can just change the value 0x0f to a different value.
> > At least, you can try commands like
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > and check the speaker output at each time.
> > Also, check the GPIO direction,
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > 	...
> >
> > Regarding the headphone: is the speaker muted when you plug in the
> > headphone?  If not, it's likely an issue of the jack detection.  If
> > the speaker is muted but no headphone output, it's a missing
> > initialization (or wrong GPIO setup).
> Setting both _DIR and _DATA to 0x08 worked, as did 0x0f.

OK, then GPIO2 is EAPD.

> Plugging in
> headphones does not mute the speaker.

I'll check this later.


thanks,

Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Tue, 07 Jul 2009 08:38:06 +0200,
I wrote:
> 
> At Tue, 07 Jul 2009 00:24:51 -0600,
> Sean Burke wrote:
> > 
> > Scríobh Takashi Iwai:
> > > At Mon, 6 Jul 2009 22:14:56 +0200,
> > > Andreas Nüßlein wrote:
> > >   
> > >> On Monday 06 July 2009 21:26:18 you wrote:
> > >>     
> > >>> At Mon, 06 Jul 2009 11:16:35 -0600,
> > >>>       
> > >>> Easy things to test are GPIO bits.  Run hda-verb like
> > >>>
> > >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > >>> or
> > >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > >>>
> > >>> etc.  CS4206 seems to have 4 GPIO lines, and each bit (0-3)
> > >>> corresponds to each GPIO.  In many case, GPIO0 or GPIO1 corresponds to
> > >>> the amplifier (EAPD) bit.
> > >>> Define the GPIO direction of each GPIO bit by SET_GPIO_DIR, and
> > >>> turn on/off the GPIO bits by SET_GPIO_DATA.  Running
> > >>> 	hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0
> > >>> will show the current GPIO data bits.  Or you can check it in codec#*
> > >>> proc file.
> > >>>
> > >>>
> > >>> Takashi
> > >>>       
> > >> w000000000000000000000000000000000t! =)
> > >>
> > >> takashi, thank you _so_ much!
> > >>
> > >> after running all 4 of those:
> > >>     
> > >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > >>> or
> > >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > >>> 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > >>>
> > >>>       
> > >> i suddendly had sound!! :D :D :D :D :D :D :D 
> > >> only via speakers  though - there is no sound via headphones right now. 
> > >>
> > >> mixer channels: 
> > >> - Master (with Mutebutton), PCM and Front (also with Mute) all work =)
> > >> - i don't know what surround would do (or it's extra switch)
> > >> - headphones-volumes and mute button don't affect the speakers, which is good 
> > >> =)
> > >>
> > >>
> > >> is there a way to reset what i did with hda-verb, so that i can figure out 
> > >> which combination it was exactly?
> > >>     
> > >
> > > You can just change the value 0x0f to a different value.
> > > At least, you can try commands like
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > > and check the speaker output at each time.
> > > Also, check the GPIO direction,
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > > 	...
> > >
> > > Regarding the headphone: is the speaker muted when you plug in the
> > > headphone?  If not, it's likely an issue of the jack detection.  If
> > > the speaker is muted but no headphone output, it's a missing
> > > initialization (or wrong GPIO setup).
> > Setting both _DIR and _DATA to 0x08 worked, as did 0x0f.
> 
> OK, then GPIO2 is EAPD.

GPIO3.

Anyway, I fixed the latest alsa-driver-unstable tree to work without
hda-verb.

> > Plugging in
> > headphones does not mute the speaker.
> 
> I'll check this later.

I don't figure out the cause yet.

Basically, HP output is always on regardless of jack plugging.
The jack plugging changes only the pin control of speakers.
So, check alsa-info.sh output (or codec#0 proc file) at HP plugged and 
unplugged states and compare the files.  If you see changes in nodes
0x0a and 0x0b (i.e. Pin-ctls becomes 0x00 from 0x40 at HP plugged),
then the driver does the right thing.  Only the hardware doesn't
respond or ignore it.

If nothing changes with HP plugged/unplugged, then either the
unsolicited event isn't generated or the jack detection doesn't work.
In either way, try to run hda-verb like

	hda-verb /dev/snd/hw0C0D0 0x0a SET_PIN_WID 0x00
	hda-verb /dev/snd/hw0C0D0 0x0b SET_PIN_WID 0x00

and see whether the speaker still works.


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Tue, 7 Jul 2009 11:49:57 +0200,
Andreas Nüßlein wrote:
> 
> On Tuesday 07 July 2009 08:00:19 you wrote:
> > At Mon, 6 Jul 2009 22:14:56 +0200,
> >
> > Andreas Nüßlein wrote:
> > > On Monday 06 July 2009 21:26:18 you wrote:
> > > > At Mon, 06 Jul 2009 11:16:35 -0600,
> > > >
> > > > Sean Burke wrote:
> > > > > Scríobh Takashi Iwai:
> > > > > > At Mon, 6 Jul 2009 17:53:46 +0200,
> > > > > >
> > > > > > Andreas Nüßlein wrote:
> > > > > >>> The missing pin configuration initialization was already fixed by
> > > > > >>> the driver overriding it after checking PCI SSID (which is
> > > > > >>> different from the codec SSID).  So, this should be no problem.
> > > > > >>>
> > > > > >>> However, the reason why the analog output doesn't work might be
> > > > > >>> different from that.  There might be something else missing, but
> > > > > >>> I don't know.
> > > > > >>>
> > > > > >>>
> > > > > >>> Takashi
> > > > > >>
> > > > > >> oh =(
> > > > > >>
> > > > > >>
> > > > > >> hmm.. anything i can do?  would it help if i tried changing values
> > > > > >> randomly with hda-analyzer.py?
> > > > > >
> > > > > > Well, did the driver without my change work more or less with
> > > > > > the analog audio, or have you never gotten the analog output?
> > > > > > You can use the generic parser (i.e. the state without cirrus
> > > > > > patch) by passing model=generic option to snd-hda-intel.
> > > > >
> > > > > For my part, nothing worked with the generic driver. I can't confirm
> > > > > digital out, but I can confirm that the kfree error is gone. What
> > > > > options are open for figuring out what remains?
> > > >
> > > > Easy things to test are GPIO bits.  Run hda-verb like
> > > >
> > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > or
> > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > >
> > > > etc.  CS4206 seems to have 4 GPIO lines, and each bit (0-3)
> > > > corresponds to each GPIO.  In many case, GPIO0 or GPIO1 corresponds to
> > > > the amplifier (EAPD) bit.
> > > > Define the GPIO direction of each GPIO bit by SET_GPIO_DIR, and
> > > > turn on/off the GPIO bits by SET_GPIO_DATA.  Running
> > > > 	hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0
> > > > will show the current GPIO data bits.  Or you can check it in codec#*
> > > > proc file.
> > > >
> > > >
> > > > Takashi
> > >
> > > w000000000000000000000000000000000t! =)
> > >
> > > takashi, thank you _so_ much!
> > >
> > > after running all 4 of those:
> > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > or
> > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > >
> > > i suddendly had sound!! :D :D :D :D :D :D :D
> > > only via speakers  though - there is no sound via headphones right now.
> > >
> > > mixer channels:
> > > - Master (with Mutebutton), PCM and Front (also with Mute) all work =)
> > > - i don't know what surround would do (or it's extra switch)
> > > - headphones-volumes and mute button don't affect the speakers, which is
> > > good =)
> > >
> > >
> > > is there a way to reset what i did with hda-verb, so that i can figure
> > > out which combination it was exactly?
> >
> > You can just change the value 0x0f to a different value.
> > At least, you can try commands like
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > and check the speaker output at each time.
> > Also, check the GPIO direction,
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02
> >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > 	...
> >
> > Regarding the headphone: is the speaker muted when you plug in the
> > headphone?  If not, it's likely an issue of the jack detection.  If
> > the speaker is muted but no headphone output, it's a missing
> > initialization (or wrong GPIO setup).
> >
> >
> > Takashi
> 
> 
> so here are my findings so far:
> 
> hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> 
> 
> is sufficient to turn on the right functionality for the speakers; meaning:
>  - 'front speaker'-channel actually controls the two front speakers within the
>    macbookpro - even controlling left and right channel seperately works  =)
>  - 'surround' mute-switch and volume-control (why are those not within on
>    thing btw?) also work and control a third speaker in the mac, which
>    really seems responsibly for surround :)
> 
> headphones do not yet work, however i made a diff of 
> "/proc/asound/card0/codec#0" with and without something plugged in:

OK, so actually the driver works as expected, but the hardware doesn't
behave as expected.  For muting the speaker, something else (like
toggling that GPIO) is needed.

The mystery about the silent HP output still remains, though.


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Tue, 07 Jul 2009 12:53:48 +0200,
I wrote:
> 
> At Tue, 7 Jul 2009 11:49:57 +0200,
> Andreas Nüßlein wrote:
> > 
> > On Tuesday 07 July 2009 08:00:19 you wrote:
> > > At Mon, 6 Jul 2009 22:14:56 +0200,
> > >
> > > Andreas Nüßlein wrote:
> > > > On Monday 06 July 2009 21:26:18 you wrote:
> > > > > At Mon, 06 Jul 2009 11:16:35 -0600,
> > > > >
> > > > > Sean Burke wrote:
> > > > > > Scríobh Takashi Iwai:
> > > > > > > At Mon, 6 Jul 2009 17:53:46 +0200,
> > > > > > >
> > > > > > > Andreas Nüßlein wrote:
> > > > > > >>> The missing pin configuration initialization was already fixed by
> > > > > > >>> the driver overriding it after checking PCI SSID (which is
> > > > > > >>> different from the codec SSID).  So, this should be no problem.
> > > > > > >>>
> > > > > > >>> However, the reason why the analog output doesn't work might be
> > > > > > >>> different from that.  There might be something else missing, but
> > > > > > >>> I don't know.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> Takashi
> > > > > > >>
> > > > > > >> oh =(
> > > > > > >>
> > > > > > >>
> > > > > > >> hmm.. anything i can do?  would it help if i tried changing values
> > > > > > >> randomly with hda-analyzer.py?
> > > > > > >
> > > > > > > Well, did the driver without my change work more or less with
> > > > > > > the analog audio, or have you never gotten the analog output?
> > > > > > > You can use the generic parser (i.e. the state without cirrus
> > > > > > > patch) by passing model=generic option to snd-hda-intel.
> > > > > >
> > > > > > For my part, nothing worked with the generic driver. I can't confirm
> > > > > > digital out, but I can confirm that the kfree error is gone. What
> > > > > > options are open for figuring out what remains?
> > > > >
> > > > > Easy things to test are GPIO bits.  Run hda-verb like
> > > > >
> > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > or
> > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > >
> > > > > etc.  CS4206 seems to have 4 GPIO lines, and each bit (0-3)
> > > > > corresponds to each GPIO.  In many case, GPIO0 or GPIO1 corresponds to
> > > > > the amplifier (EAPD) bit.
> > > > > Define the GPIO direction of each GPIO bit by SET_GPIO_DIR, and
> > > > > turn on/off the GPIO bits by SET_GPIO_DATA.  Running
> > > > > 	hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0
> > > > > will show the current GPIO data bits.  Or you can check it in codec#*
> > > > > proc file.
> > > > >
> > > > >
> > > > > Takashi
> > > >
> > > > w000000000000000000000000000000000t! =)
> > > >
> > > > takashi, thank you _so_ much!
> > > >
> > > > after running all 4 of those:
> > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > or
> > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > >
> > > > i suddendly had sound!! :D :D :D :D :D :D :D
> > > > only via speakers  though - there is no sound via headphones right now.
> > > >
> > > > mixer channels:
> > > > - Master (with Mutebutton), PCM and Front (also with Mute) all work =)
> > > > - i don't know what surround would do (or it's extra switch)
> > > > - headphones-volumes and mute button don't affect the speakers, which is
> > > > good =)
> > > >
> > > >
> > > > is there a way to reset what i did with hda-verb, so that i can figure
> > > > out which combination it was exactly?
> > >
> > > You can just change the value 0x0f to a different value.
> > > At least, you can try commands like
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > > and check the speaker output at each time.
> > > Also, check the GPIO direction,
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02
> > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > > 	...
> > >
> > > Regarding the headphone: is the speaker muted when you plug in the
> > > headphone?  If not, it's likely an issue of the jack detection.  If
> > > the speaker is muted but no headphone output, it's a missing
> > > initialization (or wrong GPIO setup).
> > >
> > >
> > > Takashi
> > 
> > 
> > so here are my findings so far:
> > 
> > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > 
> > 
> > is sufficient to turn on the right functionality for the speakers; meaning:
> >  - 'front speaker'-channel actually controls the two front speakers within the
> >    macbookpro - even controlling left and right channel seperately works  =)
> >  - 'surround' mute-switch and volume-control (why are those not within on
> >    thing btw?) also work and control a third speaker in the mac, which
> >    really seems responsibly for surround :)
> > 
> > headphones do not yet work, however i made a diff of 
> > "/proc/asound/card0/codec#0" with and without something plugged in:
> 
> OK, so actually the driver works as expected, but the hardware doesn't
> behave as expected.  For muting the speaker, something else (like
> toggling that GPIO) is needed.
> 
> The mystery about the silent HP output still remains, though.

One another thing we can try is to use only one PCM stream instead of
multi streams.  For example, try the patch below.  This will enable
only the pin for the headphone, thus only one DAC is used.


Takashi

---
diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c
index 57251d7..d7f52b1 100644
--- a/sound/pci/hda/patch_cirrus.c
+++ b/sound/pci/hda/patch_cirrus.c
@@ -1086,13 +1086,17 @@ struct cs_pincfg {
 
 static struct cs_pincfg mbp55_pincfgs[] = {
 	{ 0x09, 0x012b4030 },
-	{ 0x0a, 0x90100121 },
-	{ 0x0b, 0x90100120 },
+	// { 0x0a, 0x90100121 },
+	{ 0x0a, 0x400000f0 },
+	// { 0x0b, 0x90100120 },
+	{ 0x0b, 0x400000f0 },
 	{ 0x0c, 0x400000f0 },
-	{ 0x0d, 0x90a00110 },
+	// { 0x0d, 0x90a00110 },
+	{ 0x0d, 0x400000f0 },
 	{ 0x0e, 0x400000f0 },
 	{ 0x0f, 0x400000f0 },
-	{ 0x10, 0x014be040 },
+	// { 0x10, 0x014be040 },
+	{ 0x10, 0x400000f0 },
 	{ 0x12, 0x400000f0 },
 	{ 0x15, 0x400000f0 },
 	{} /* terminator */

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Wed, 8 Jul 2009 18:11:29 +0200,
Andreas Nüßlein wrote:
> 
> On Wednesday 08 July 2009 16:49:34 you wrote:
> > At Tue, 07 Jul 2009 12:53:48 +0200,
> >
> > I wrote:
> > > At Tue, 7 Jul 2009 11:49:57 +0200,
> > >
> > > Andreas Nüßlein wrote:
> > > > On Tuesday 07 July 2009 08:00:19 you wrote:
> > > > > At Mon, 6 Jul 2009 22:14:56 +0200,
> > > > >
> > > > > Andreas Nüßlein wrote:
> > > > > > On Monday 06 July 2009 21:26:18 you wrote:
> > > > > > > At Mon, 06 Jul 2009 11:16:35 -0600,
> > > > > > >
> > > > > > > Sean Burke wrote:
> > > > > > > > Scríobh Takashi Iwai:
> > > > > > > > > At Mon, 6 Jul 2009 17:53:46 +0200,
> > > > > > > > >
> > > > > > > > > Andreas Nüßlein wrote:
> > > > > > > > >>> The missing pin configuration initialization was already
> > > > > > > > >>> fixed by the driver overriding it after checking PCI SSID
> > > > > > > > >>> (which is different from the codec SSID).  So, this should
> > > > > > > > >>> be no problem.
> > > > > > > > >>>
> > > > > > > > >>> However, the reason why the analog output doesn't work
> > > > > > > > >>> might be different from that.  There might be something
> > > > > > > > >>> else missing, but I don't know.
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>> Takashi
> > > > > > > > >>
> > > > > > > > >> oh =(
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> hmm.. anything i can do?  would it help if i tried changing
> > > > > > > > >> values randomly with hda-analyzer.py?
> > > > > > > > >
> > > > > > > > > Well, did the driver without my change work more or less with
> > > > > > > > > the analog audio, or have you never gotten the analog output?
> > > > > > > > > You can use the generic parser (i.e. the state without cirrus
> > > > > > > > > patch) by passing model=generic option to snd-hda-intel.
> > > > > > > >
> > > > > > > > For my part, nothing worked with the generic driver. I can't
> > > > > > > > confirm digital out, but I can confirm that the kfree error is
> > > > > > > > gone. What options are open for figuring out what remains?
> > > > > > >
> > > > > > > Easy things to test are GPIO bits.  Run hda-verb like
> > > > > > >
> > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > or
> > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > >
> > > > > > > etc.  CS4206 seems to have 4 GPIO lines, and each bit (0-3)
> > > > > > > corresponds to each GPIO.  In many case, GPIO0 or GPIO1
> > > > > > > corresponds to the amplifier (EAPD) bit.
> > > > > > > Define the GPIO direction of each GPIO bit by SET_GPIO_DIR, and
> > > > > > > turn on/off the GPIO bits by SET_GPIO_DATA.  Running
> > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0
> > > > > > > will show the current GPIO data bits.  Or you can check it in
> > > > > > > codec#* proc file.
> > > > > > >
> > > > > > >
> > > > > > > Takashi
> > > > > >
> > > > > > w000000000000000000000000000000000t! =)
> > > > > >
> > > > > > takashi, thank you _so_ much!
> > > > > >
> > > > > > after running all 4 of those:
> > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > or
> > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > >
> > > > > > i suddendly had sound!! :D :D :D :D :D :D :D
> > > > > > only via speakers  though - there is no sound via headphones right
> > > > > > now.
> > > > > >
> > > > > > mixer channels:
> > > > > > - Master (with Mutebutton), PCM and Front (also with Mute) all work
> > > > > > =) - i don't know what surround would do (or it's extra switch) -
> > > > > > headphones-volumes and mute button don't affect the speakers, which
> > > > > > is good =)
> > > > > >
> > > > > >
> > > > > > is there a way to reset what i did with hda-verb, so that i can
> > > > > > figure out which combination it was exactly?
> > > > >
> > > > > You can just change the value 0x0f to a different value.
> > > > > At least, you can try commands like
> > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04
> > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > > > > and check the speaker output at each time.
> > > > > Also, check the GPIO direction,
> > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01
> > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02
> > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > > > > 	...
> > > > >
> > > > > Regarding the headphone: is the speaker muted when you plug in the
> > > > > headphone?  If not, it's likely an issue of the jack detection.  If
> > > > > the speaker is muted but no headphone output, it's a missing
> > > > > initialization (or wrong GPIO setup).
> > > > >
> > > > >
> > > > > Takashi
> > > >
> > > > so here are my findings so far:
> > > >
> > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > > >
> > > >
> > > > is sufficient to turn on the right functionality for the speakers;
> > > > meaning: - 'front speaker'-channel actually controls the two front
> > > > speakers within the macbookpro - even controlling left and right
> > > > channel seperately works  =) - 'surround' mute-switch and
> > > > volume-control (why are those not within on thing btw?) also work and
> > > > control a third speaker in the mac, which really seems responsibly for
> > > > surround :)
> > > >
> > > > headphones do not yet work, however i made a diff of
> > > > "/proc/asound/card0/codec#0" with and without something plugged in:
> > >
> > > OK, so actually the driver works as expected, but the hardware doesn't
> > > behave as expected.  For muting the speaker, something else (like
> > > toggling that GPIO) is needed.
> > >
> > > The mystery about the silent HP output still remains, though.
> >
> > One another thing we can try is to use only one PCM stream instead of
> > multi streams.  For example, try the patch below.  This will enable
> > only the pin for the headphone, thus only one DAC is used.
> >
> >
> > Takashi
> >
> > ---
> > diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c
> > index 57251d7..d7f52b1 100644
> > --- a/sound/pci/hda/patch_cirrus.c
> > +++ b/sound/pci/hda/patch_cirrus.c
> > @@ -1086,13 +1086,17 @@ struct cs_pincfg {
> >
> >  static struct cs_pincfg mbp55_pincfgs[] = {
> >  	{ 0x09, 0x012b4030 },
> > -	{ 0x0a, 0x90100121 },
> > -	{ 0x0b, 0x90100120 },
> > +	// { 0x0a, 0x90100121 },
> > +	{ 0x0a, 0x400000f0 },
> > +	// { 0x0b, 0x90100120 },
> > +	{ 0x0b, 0x400000f0 },
> >  	{ 0x0c, 0x400000f0 },
> > -	{ 0x0d, 0x90a00110 },
> > +	// { 0x0d, 0x90a00110 },
> > +	{ 0x0d, 0x400000f0 },
> >  	{ 0x0e, 0x400000f0 },
> >  	{ 0x0f, 0x400000f0 },
> > -	{ 0x10, 0x014be040 },
> > +	// { 0x10, 0x014be040 },
> > +	{ 0x10, 0x400000f0 },
> >  	{ 0x12, 0x400000f0 },
> >  	{ 0x15, 0x400000f0 },
> >  	{} /* terminator */
> 
> 
> =( no  - that doesn't work either
> 
> (there is obivously no sound via built-in speakers either anymore)

Hmm, then I have really no clue.
At best, you can try again GPIO pins and reverting COEF setup by my
earlier patch, and try some more adjustments of widgets amp or pinctl
via hda-verb or hda-analyzer...


Takashi

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Andreas Nüßlein]

On Thursday 09 July 2009 09:18:57 you wrote:
> At Wed, 8 Jul 2009 18:11:29 +0200,
>
> Andreas Nüßlein wrote:
> > On Wednesday 08 July 2009 16:49:34 you wrote:
> > > At Tue, 07 Jul 2009 12:53:48 +0200,
> > >
> > > I wrote:
> > > > At Tue, 7 Jul 2009 11:49:57 +0200,
> > > >
> > > > Andreas Nüßlein wrote:
> > > > > On Tuesday 07 July 2009 08:00:19 you wrote:
> > > > > > At Mon, 6 Jul 2009 22:14:56 +0200,
> > > > > >
> > > > > > Andreas Nüßlein wrote:
> > > > > > > On Monday 06 July 2009 21:26:18 you wrote:
> > > > > > > > At Mon, 06 Jul 2009 11:16:35 -0600,
> > > > > > > >
> > > > > > > > Sean Burke wrote:
> > > > > > > > > Scríobh Takashi Iwai:
> > > > > > > > > > At Mon, 6 Jul 2009 17:53:46 +0200,
> > > > > > > > > >
> > > > > > > > > > Andreas Nüßlein wrote:
> > > > > > > > > >>> The missing pin configuration initialization was
> > > > > > > > > >>> already fixed by the driver overriding it after
> > > > > > > > > >>> checking PCI SSID (which is different from the codec
> > > > > > > > > >>> SSID).  So, this should be no problem.
> > > > > > > > > >>>
> > > > > > > > > >>> However, the reason why the analog output doesn't work
> > > > > > > > > >>> might be different from that.  There might be something
> > > > > > > > > >>> else missing, but I don't know.
> > > > > > > > > >>>
> > > > > > > > > >>>
> > > > > > > > > >>> Takashi
> > > > > > > > > >>
> > > > > > > > > >> oh =(
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> hmm.. anything i can do?  would it help if i tried
> > > > > > > > > >> changing values randomly with hda-analyzer.py?
> > > > > > > > > >
> > > > > > > > > > Well, did the driver without my change work more or less
> > > > > > > > > > with the analog audio, or have you never gotten the
> > > > > > > > > > analog output? You can use the generic parser (i.e. the
> > > > > > > > > > state without cirrus patch) by passing model=generic
> > > > > > > > > > option to snd-hda-intel.
> > > > > > > > >
> > > > > > > > > For my part, nothing worked with the generic driver. I
> > > > > > > > > can't confirm digital out, but I can confirm that the kfree
> > > > > > > > > error is gone. What options are open for figuring out what
> > > > > > > > > remains?
> > > > > > > >
> > > > > > > > Easy things to test are GPIO bits.  Run hda-verb like
> > > > > > > >
> > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > > or
> > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > >
> > > > > > > > etc.  CS4206 seems to have 4 GPIO lines, and each bit (0-3)
> > > > > > > > corresponds to each GPIO.  In many case, GPIO0 or GPIO1
> > > > > > > > corresponds to the amplifier (EAPD) bit.
> > > > > > > > Define the GPIO direction of each GPIO bit by SET_GPIO_DIR,
> > > > > > > > and turn on/off the GPIO bits by SET_GPIO_DATA.  Running
> > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0
> > > > > > > > will show the current GPIO data bits.  Or you can check it in
> > > > > > > > codec#* proc file.
> > > > > > > >
> > > > > > > >
> > > > > > > > Takashi
> > > > > > >
> > > > > > > w000000000000000000000000000000000t! =)
> > > > > > >
> > > > > > > takashi, thank you _so_ much!
> > > > > > >
> > > > > > > after running all 4 of those:
> > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > > or
> > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > >
> > > > > > > i suddendly had sound!! :D :D :D :D :D :D :D
> > > > > > > only via speakers  though - there is no sound via headphones
> > > > > > > right now.
> > > > > > >
> > > > > > > mixer channels:
> > > > > > > - Master (with Mutebutton), PCM and Front (also with Mute) all
> > > > > > > work =) - i don't know what surround would do (or it's extra
> > > > > > > switch) - headphones-volumes and mute button don't affect the
> > > > > > > speakers, which is good =)
> > > > > > >
> > > > > > >
> > > > > > > is there a way to reset what i did with hda-verb, so that i can
> > > > > > > figure out which combination it was exactly?
> > > > > >
> > > > > > You can just change the value 0x0f to a different value.
> > > > > > At least, you can try commands like
> > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04
> > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > > > > > and check the speaker output at each time.
> > > > > > Also, check the GPIO direction,
> > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01
> > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02
> > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > > > > > 	...
> > > > > >
> > > > > > Regarding the headphone: is the speaker muted when you plug in
> > > > > > the headphone?  If not, it's likely an issue of the jack
> > > > > > detection.  If the speaker is muted but no headphone output, it's
> > > > > > a missing initialization (or wrong GPIO setup).
> > > > > >
> > > > > >
> > > > > > Takashi
> > > > >
> > > > > so here are my findings so far:
> > > > >
> > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > > > >
> > > > >
> > > > > is sufficient to turn on the right functionality for the speakers;
> > > > > meaning: - 'front speaker'-channel actually controls the two front
> > > > > speakers within the macbookpro - even controlling left and right
> > > > > channel seperately works  =) - 'surround' mute-switch and
> > > > > volume-control (why are those not within on thing btw?) also work
> > > > > and control a third speaker in the mac, which really seems
> > > > > responsibly for surround :)
> > > > >
> > > > > headphones do not yet work, however i made a diff of
> > > > > "/proc/asound/card0/codec#0" with and without something plugged in:
> > > >
> > > > OK, so actually the driver works as expected, but the hardware
> > > > doesn't behave as expected.  For muting the speaker, something else
> > > > (like toggling that GPIO) is needed.
> > > >
> > > > The mystery about the silent HP output still remains, though.
> > >
> > > One another thing we can try is to use only one PCM stream instead of
> > > multi streams.  For example, try the patch below.  This will enable
> > > only the pin for the headphone, thus only one DAC is used.
> > >
> > >
> > > Takashi
> > >
> > > ---
> > > diff --git a/sound/pci/hda/patch_cirrus.c
> > > b/sound/pci/hda/patch_cirrus.c index 57251d7..d7f52b1 100644
> > > --- a/sound/pci/hda/patch_cirrus.c
> > > +++ b/sound/pci/hda/patch_cirrus.c
> > > @@ -1086,13 +1086,17 @@ struct cs_pincfg {
> > >
> > >  static struct cs_pincfg mbp55_pincfgs[] = {
> > >  	{ 0x09, 0x012b4030 },
> > > -	{ 0x0a, 0x90100121 },
> > > -	{ 0x0b, 0x90100120 },
> > > +	// { 0x0a, 0x90100121 },
> > > +	{ 0x0a, 0x400000f0 },
> > > +	// { 0x0b, 0x90100120 },
> > > +	{ 0x0b, 0x400000f0 },
> > >  	{ 0x0c, 0x400000f0 },
> > > -	{ 0x0d, 0x90a00110 },
> > > +	// { 0x0d, 0x90a00110 },
> > > +	{ 0x0d, 0x400000f0 },
> > >  	{ 0x0e, 0x400000f0 },
> > >  	{ 0x0f, 0x400000f0 },
> > > -	{ 0x10, 0x014be040 },
> > > +	// { 0x10, 0x014be040 },
> > > +	{ 0x10, 0x400000f0 },
> > >  	{ 0x12, 0x400000f0 },
> > >  	{ 0x15, 0x400000f0 },
> > >  	{} /* terminator */
> >
> > =( no  - that doesn't work either
> >
> > (there is obivously no sound via built-in speakers either anymore)
>
> Hmm, then I have really no clue.
> At best, you can try again GPIO pins and reverting COEF setup by my
> earlier patch, and try some more adjustments of widgets amp or pinctl
> via hda-verb or hda-analyzer...
>
>
> Takashi


still no luck on my end =(

however i found this, while google-ing  on datasheetarchive.com:
http://nutz.unfoog.de/cs4206.pdf

there's a lot of stuff about the pins and all that. maybe this is helpfull?


is there anything i can do, though?  like: try a bunch of different keys/codes 
somewhere? 

to get this right: Node[0x09] is getting "sound" just like 0x0a and 0x0b; 0x0a 
passes the sound to 0x03 (which is surround) and 0x0b passes it to 0x04 (which 
is front speaker).
0x09 should pass the sound to 0x02, then? and is that definitely working, 
making 0x02 the problem? or is maybe 0x09 wrong somehow already?  i don't 
really get the alsa-interna yet. =(

thanks
andy

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Andreas Nüßlein]

> however i found this, while google-ing  on datasheetarchive.com:
> http://nutz.unfoog.de/cs4206.pdf
>

i just realized that this is an old document - datasheetarchive labeled it as 
cs4206 though :S

sorry

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Fri, 10 Jul 2009 02:27:57 +0200,
Andreas Nüßlein wrote:
> 
> On Thursday 09 July 2009 09:18:57 you wrote:
> > At Wed, 8 Jul 2009 18:11:29 +0200,
> >
> > Andreas Nüßlein wrote:
> > > On Wednesday 08 July 2009 16:49:34 you wrote:
> > > > At Tue, 07 Jul 2009 12:53:48 +0200,
> > > >
> > > > I wrote:
> > > > > At Tue, 7 Jul 2009 11:49:57 +0200,
> > > > >
> > > > > Andreas Nüßlein wrote:
> > > > > > On Tuesday 07 July 2009 08:00:19 you wrote:
> > > > > > > At Mon, 6 Jul 2009 22:14:56 +0200,
> > > > > > >
> > > > > > > Andreas Nüßlein wrote:
> > > > > > > > On Monday 06 July 2009 21:26:18 you wrote:
> > > > > > > > > At Mon, 06 Jul 2009 11:16:35 -0600,
> > > > > > > > >
> > > > > > > > > Sean Burke wrote:
> > > > > > > > > > Scríobh Takashi Iwai:
> > > > > > > > > > > At Mon, 6 Jul 2009 17:53:46 +0200,
> > > > > > > > > > >
> > > > > > > > > > > Andreas Nüßlein wrote:
> > > > > > > > > > >>> The missing pin configuration initialization was
> > > > > > > > > > >>> already fixed by the driver overriding it after
> > > > > > > > > > >>> checking PCI SSID (which is different from the codec
> > > > > > > > > > >>> SSID).  So, this should be no problem.
> > > > > > > > > > >>>
> > > > > > > > > > >>> However, the reason why the analog output doesn't work
> > > > > > > > > > >>> might be different from that.  There might be something
> > > > > > > > > > >>> else missing, but I don't know.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>> Takashi
> > > > > > > > > > >>
> > > > > > > > > > >> oh =(
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> hmm.. anything i can do?  would it help if i tried
> > > > > > > > > > >> changing values randomly with hda-analyzer.py?
> > > > > > > > > > >
> > > > > > > > > > > Well, did the driver without my change work more or less
> > > > > > > > > > > with the analog audio, or have you never gotten the
> > > > > > > > > > > analog output? You can use the generic parser (i.e. the
> > > > > > > > > > > state without cirrus patch) by passing model=generic
> > > > > > > > > > > option to snd-hda-intel.
> > > > > > > > > >
> > > > > > > > > > For my part, nothing worked with the generic driver. I
> > > > > > > > > > can't confirm digital out, but I can confirm that the kfree
> > > > > > > > > > error is gone. What options are open for figuring out what
> > > > > > > > > > remains?
> > > > > > > > >
> > > > > > > > > Easy things to test are GPIO bits.  Run hda-verb like
> > > > > > > > >
> > > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > > > or
> > > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > > >
> > > > > > > > > etc.  CS4206 seems to have 4 GPIO lines, and each bit (0-3)
> > > > > > > > > corresponds to each GPIO.  In many case, GPIO0 or GPIO1
> > > > > > > > > corresponds to the amplifier (EAPD) bit.
> > > > > > > > > Define the GPIO direction of each GPIO bit by SET_GPIO_DIR,
> > > > > > > > > and turn on/off the GPIO bits by SET_GPIO_DATA.  Running
> > > > > > > > > hda-verb /dev/snd/hwC0D0 0x01 GET_GPIO_DATA 0
> > > > > > > > > will show the current GPIO data bits.  Or you can check it in
> > > > > > > > > codec#* proc file.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Takashi
> > > > > > > >
> > > > > > > > w000000000000000000000000000000000t! =)
> > > > > > > >
> > > > > > > > takashi, thank you _so_ much!
> > > > > > > >
> > > > > > > > after running all 4 of those:
> > > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x0f
> > > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > > > or
> > > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x0f
> > > > > > > > > 	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0f
> > > > > > > >
> > > > > > > > i suddendly had sound!! :D :D :D :D :D :D :D
> > > > > > > > only via speakers  though - there is no sound via headphones
> > > > > > > > right now.
> > > > > > > >
> > > > > > > > mixer channels:
> > > > > > > > - Master (with Mutebutton), PCM and Front (also with Mute) all
> > > > > > > > work =) - i don't know what surround would do (or it's extra
> > > > > > > > switch) - headphones-volumes and mute button don't affect the
> > > > > > > > speakers, which is good =)
> > > > > > > >
> > > > > > > >
> > > > > > > > is there a way to reset what i did with hda-verb, so that i can
> > > > > > > > figure out which combination it was exactly?
> > > > > > >
> > > > > > > You can just change the value 0x0f to a different value.
> > > > > > > At least, you can try commands like
> > > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04
> > > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > > > > > > and check the speaker output at each time.
> > > > > > > Also, check the GPIO direction,
> > > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01
> > > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
> > > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x02
> > > > > > >  	hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x02
> > > > > > > 	...
> > > > > > >
> > > > > > > Regarding the headphone: is the speaker muted when you plug in
> > > > > > > the headphone?  If not, it's likely an issue of the jack
> > > > > > > detection.  If the speaker is muted but no headphone output, it's
> > > > > > > a missing initialization (or wrong GPIO setup).
> > > > > > >
> > > > > > >
> > > > > > > Takashi
> > > > > >
> > > > > > so here are my findings so far:
> > > > > >
> > > > > > hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x08
> > > > > >
> > > > > >
> > > > > > is sufficient to turn on the right functionality for the speakers;
> > > > > > meaning: - 'front speaker'-channel actually controls the two front
> > > > > > speakers within the macbookpro - even controlling left and right
> > > > > > channel seperately works  =) - 'surround' mute-switch and
> > > > > > volume-control (why are those not within on thing btw?) also work
> > > > > > and control a third speaker in the mac, which really seems
> > > > > > responsibly for surround :)
> > > > > >
> > > > > > headphones do not yet work, however i made a diff of
> > > > > > "/proc/asound/card0/codec#0" with and without something plugged in:
> > > > >
> > > > > OK, so actually the driver works as expected, but the hardware
> > > > > doesn't behave as expected.  For muting the speaker, something else
> > > > > (like toggling that GPIO) is needed.
> > > > >
> > > > > The mystery about the silent HP output still remains, though.
> > > >
> > > > One another thing we can try is to use only one PCM stream instead of
> > > > multi streams.  For example, try the patch below.  This will enable
> > > > only the pin for the headphone, thus only one DAC is used.
> > > >
> > > >
> > > > Takashi
> > > >
> > > > ---
> > > > diff --git a/sound/pci/hda/patch_cirrus.c
> > > > b/sound/pci/hda/patch_cirrus.c index 57251d7..d7f52b1 100644
> > > > --- a/sound/pci/hda/patch_cirrus.c
> > > > +++ b/sound/pci/hda/patch_cirrus.c
> > > > @@ -1086,13 +1086,17 @@ struct cs_pincfg {
> > > >
> > > >  static struct cs_pincfg mbp55_pincfgs[] = {
> > > >  	{ 0x09, 0x012b4030 },
> > > > -	{ 0x0a, 0x90100121 },
> > > > -	{ 0x0b, 0x90100120 },
> > > > +	// { 0x0a, 0x90100121 },
> > > > +	{ 0x0a, 0x400000f0 },
> > > > +	// { 0x0b, 0x90100120 },
> > > > +	{ 0x0b, 0x400000f0 },
> > > >  	{ 0x0c, 0x400000f0 },
> > > > -	{ 0x0d, 0x90a00110 },
> > > > +	// { 0x0d, 0x90a00110 },
> > > > +	{ 0x0d, 0x400000f0 },
> > > >  	{ 0x0e, 0x400000f0 },
> > > >  	{ 0x0f, 0x400000f0 },
> > > > -	{ 0x10, 0x014be040 },
> > > > +	// { 0x10, 0x014be040 },
> > > > +	{ 0x10, 0x400000f0 },
> > > >  	{ 0x12, 0x400000f0 },
> > > >  	{ 0x15, 0x400000f0 },
> > > >  	{} /* terminator */
> > >
> > > =( no  - that doesn't work either
> > >
> > > (there is obivously no sound via built-in speakers either anymore)
> >
> > Hmm, then I have really no clue.
> > At best, you can try again GPIO pins and reverting COEF setup by my
> > earlier patch, and try some more adjustments of widgets amp or pinctl
> > via hda-verb or hda-analyzer...
> >
> >
> > Takashi
> 
> 
> still no luck on my end =(
> 
> however i found this, while google-ing  on datasheetarchive.com:
> http://nutz.unfoog.de/cs4206.pdf
> 
> there's a lot of stuff about the pins and all that. maybe this is helpfull?
> 
> 
> is there anything i can do, though?  like: try a bunch of different keys/codes 
> somewhere? 
> 
> to get this right: Node[0x09] is getting "sound" just like 0x0a and 0x0b; 0x0a 
> passes the sound to 0x03 (which is surround) and 0x0b passes it to 0x04 (which 
> is front speaker).
> 0x09 should pass the sound to 0x02, then? and is that definitely working, 
> making 0x02 the problem? or is maybe 0x09 wrong somehow already?  i don't 
> really get the alsa-interna yet. =(

Well, your question is rather HD-audio codec specific than ALSA.
CS420x has a 1:1 static connection between DAC and pin, according to the
codec verbs.  The pin 0x09 corresponds to the DAC 0x02, and this appears
to be a HP output.  It's just labeled so, and thus it's a guess.

You can change the pin configs in mbp55_pincfgs[] just to point one
pin.  In the case above, 0x012b4030 is set to 0x09 (which represents
a HP output) and others are 0x400000f0 (which represents empty).
Similarly, you can assign the value to another pin and check which I/O
actually works...

And, this might be together with GPIO setup.  So, a lot of
trial-and-error procedure.


Takashi

No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Andreas Nuesslein]

[-- Attachment #1.1: Type: text/plain, Size: 1232 bytes --]

I just got a macbookpro (mid2009 version) with a new nvidia chipset.

there is no sound at all. neither via the built-in speakers nor via
out-jack.

i tried aplay -D myfile.wav with everything from aplay -L  as well.

i also tried a recent snapshot (alsa-driver-20090626.tar.bz2) as well
as gentoo ebuilds alsa-headers-9999 and alsa-driver-9999 (which uses
git to pull recent versions).

so here's a little information i can gather:

$ lspci -s 00:08.0 -v
00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio
(rev b1) Subsystem: nVidia Corporation Device cb79
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23
        Memory at d3480000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: HDA Intel
        Kernel modules: snd-hda-intel


alsa-info:
http://www.alsa-project.org/db/?f=80e89b82fec184b68a88b9ed4128544a276775fc

modinfo snd-hda-intel:
http://www.nopaste.com/p/a3B7miINP

i also found a thread about that problem (w/o solution obviously):

http://www.uluga.ubuntuforums.org/showthread.php?t=1188849&page=2


hope that's all information necessary.

if i can i'd love to help in some way.

thanks

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: No sound with nVidia Corporation MCP79 High Definition Audio (rev b1) (Macbook Pro 5, 5)

[Takashi Iwai]

At Sat, 27 Jun 2009 03:16:54 +0200,
Andreas Nuesslein wrote:
> 
> I just got a macbookpro (mid2009 version) with a new nvidia chipset.
> 
> there is no sound at all. neither via the built-in speakers nor via
> out-jack.
> 
> i tried aplay -D myfile.wav with everything from aplay -L  as well.
> 
> i also tried a recent snapshot (alsa-driver-20090626.tar.bz2) as well
> as gentoo ebuilds alsa-headers-9999 and alsa-driver-9999 (which uses
> git to pull recent versions).
> 
> so here's a little information i can gather:
> 
> $ lspci -s 00:08.0 -v
> 00:08.0 Audio device: nVidia Corporation MCP79 High Definition Audio
> (rev b1) Subsystem: nVidia Corporation Device cb79
>         Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23
>         Memory at d3480000 (32-bit, non-prefetchable) [size=16K]
>         Capabilities: <access denied>
>         Kernel driver in use: HDA Intel
>         Kernel modules: snd-hda-intel
> 
> 
> alsa-info:
> http://www.alsa-project.org/db/?f=80e89b82fec184b68a88b9ed4128544a276775fc

Interesting.  This is really an unknown codec chip (1013:4206).
Which vendor/product of the codec chip is this?
(Oh, it's a Mac.  So Apple won't say anything specific?)


Takashi