[alsa-devel] Status of CMI9738 and SiS7012

Takashi Iwai tiwai at suse.de
Thu Mar 29 12:29:21 CEST 2007


At Wed, 28 Mar 2007 11:58:50 -0600,
Rob Franklin wrote:
> 
> On 3/28/07, Takashi Iwai <tiwai at suse.de> wrote:
> > Hi,
> >
> > Please don't drop Cc to alsa-devel...
> >
> > At Wed, 28 Mar 2007 10:23:22 -0600,
> > Rob Franklin wrote:
> > >
> > > On 3/28/07, Takashi Iwai <tiwai at suse.de> wrote:
> > > > At Tue, 27 Mar 2007 10:44:23 -0600,
> > > > Rob Franklin wrote:
> > > > >
> > > > > On 3/27/07, Takashi Iwai <tiwai at suse.de> wrote:
> > > > > > At Tue, 27 Mar 2007 08:49:05 -0600,
> > > > > > Rob Franklin wrote:
> > > > > > >
> > > > > > > Hi All,
> > > > > > >
> > > > > > > I posted a question a couple of weeks ago to the alsa-users list
> > > > > > > (Can't get spdif working with ALSA and FC6 on ECS L4S5MG/651+
> > > > > > > motherboard), but never got a response.
> > > > > > >
> > > > > > > I have been looking at the ALSA source code for the AC'97 codec on my
> > > > > > > board  (CMI9738) and the source code for the intel8x0 driver (for my
> > > > > > > SiS 7012).  However, as far as I can tell from looking at the source,
> > > > > > > S/PDIF is not enabled/supported for this combination of devices.
> > > > > > > Additionally, Googling around I haven't found any mention of people
> > > > > > > getting spdif working with ALSA and a CM9738 / SiS7012 combo.
> > > > > > >
> > > > > > > I am wondering whether anyone on the developer list can confirm that
> > > > > > > this is the case.  Also, if this is the case can someone give me an
> > > > > > > idea of what would be required to get this working.  The system is
> > > > > > > setup with dual boot and so I could grab some of the values from
> > > > > > > windows using a PCI sniffer, and I might be able to do some hacking on
> > > > > > > the source code and submit a patch if someone could help guide me in
> > > > > > > the right direction.
> > > > > >
> > > > > > Are you sure it's CM9738?  AFAIK, CM9738 doesn't support SPDIF at
> > > > > > all, but CM9739 does...
> > > > > >
> > > > > That was my first thought too, but I pulled open the case last night
> > > > > and verified that it was indeed a 9738.  The download page from the
> > > > > motherboard manufacturer has a driver for CMI9738 and a CMI9738/9739
> > > > > driver (http://www.ecsusa.com/downloads/drivers_sound.html).  I am
> > > > > wondering if there are two different versions of this chip.
> > > > >
> > > > > Here is the output from lspci -vv for the sound device:
> > > > >
> > > > > 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS]
> > > > > AC'97 Sound Controller (rev a0)
> > > > >         Subsystem: Elitegroup Computer Systems Unknown device 0a44
> > > > >         Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > > > > ParErr- Stepping- SERR- FastB2B-
> > > > >         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
> > > > > >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> > > > >         Latency: 32 (13000ns min, 2750ns max)
> > > > >         Interrupt: pin C routed to IRQ 22
> > > > >         Region 0: I/O ports at d000 [size=256]
> > > > >         Region 1: I/O ports at d400 [size=128]
> > > > >         Capabilities: <access denied>
> > > > >
> > > > > One thought that I had was to force the AC'97 driver to detect the
> > > > > chip as a 9739 instead of a 9738 to see whether my 9738 can work as a
> > > > > 9739.  But I'm not sure how to do that short of modifying the source
> > > > > code and recompiling the kernel module.
> > > >
> > > > First check whether its codec id is CMI9738, see
> > > > /proc/asound/card0/codec97#0/* files.  If it's really CM9738, you can
> > > > hack pci/ac97/ac97_codec.c to replace patch_cm9738 with patch_cm9739
> > > > in snd_ac97_codec_ids[].
> > > >
> > > Here are the first couple of lines from /proc/asound/card0/codec97#0/ac97#0-0 :
> > >
> > > 0-0/0: C-Media Electronics CMI9738
> > >
> > > PCI Subsys Vendor: 0x1019
> > > PCI Subsys Device: 0x0a44
> > >
> > > Last night I hacked the ac97_codec.c and recompiled snd-ac97-codec.ko,
> > > and now the file reads
> > >
> > > 0-0/0: C-Media Electronics -- rob CMI9739
> > >
> > > Everything seems to be working the same as it was before, and I can
> > > get stereo sound from the line-out jack just fine.  However, when I
> > > try to play back sound using the spdif I get the following:
> > >
> > > $ aplay -D plug:iec958 ac3_48khz_diatonis_soal.ac3
> > > ALSA lib setup.c:555:(add_elem) Cannot obtain info for CTL elem
> > > (MIXER,'IEC958 Playback Default',0,0,0): No such file or directory
> >
> > I guess the control element wasn't created indeed because of lack of
> > SPDIF feature on the codec.
> >
> > patch_cm9739() checks the availability of SPDIF bit (SPCV) and turn
> > off the whole SPDIF feature if the bit isn't set.  You can avoid that
> > check just for testing.
> >
> > If this doesn't work, the possible situation is that the SPDIF is
> > transmitted directly from the controller chip without AC97 codec.
> > Unfortunately, we have no hardware information about SIS7012, so don't
> > know whether it's even possible, and how to control it.
> >
> > > Is there a script I need to run or file I need to update my list of
> > > CTLs (I have seen references to alsaconf and snddev on the web but
> > > neither seems to be included with my FC5 install of alsa-utils)?
> >
> > % alsactl -f somefile store
> >
> > > Also, is there any easy way to reload the snd-ac97-codec.ko module.  I
> > > tried removing the modules with "rmmod snd-ac97-codec" and "modprobe
> > > snd-ac97-codec".  The module came out ok, but I got a  bunch of errors
> > > like this when I tried to reinsert the modules:
> > >
> > > Mar 27 21:16:46 XXXX kernel: snd_ac97_codec: Unknown symbol snd_info_register
> > > Mar 27 21:16:46 XXXX kernel: snd_ac97_codec: disagrees about version
> > > of symbol snd_ctl_add
> > >
> > > So right now I am rebooting the machine every time I want to replace
> > > snd-ac97-codec.
> >
> > Seems that you still have the old modules on memory while installing
> > the new modules.  First unload all snd related modules, then reload
> > again.
> >
> > Otherwise, something wrong with the build with your kernel tree.
> > I never used FC or RedHat, so can't answer about it.
> >
> OK. Thanks.  I made you suggested modifications to the code, and I
> will recompile and try it out tonight when I get home.  I also sent a
> datasheet request to the SiS development team for the SiS7012
> datasheet.  Probably a long shot, but you never know.  It might pan
> out.
> 
> I also looked at a datasheet (Apr. 2002 Rev 1.1) for the CMI9738 and
> the only digital output that I can see is the SDATA_OUT line which I
> believe is a part of the AC-Link bus.  Could this line also be tapped
> to provide an spdif output?

It's a serial line for the whole outputs.  Usually slot 10/11 is used
for SPDIF output in it.

>  If so, I noticed some code in intel8x0.c
> that uses an undocumented module option:
> 
> module_param(spdif_aclink, int, 0444);
> MODULE_PARM_DESC(spdif_aclink, "S/PDIF over AC-link.");
> 
> Looking through the code right now, this module option doesn't seem to
> have any effect on SiS7012 devices.  However, if some of the other
> intel8x0 devices enable S/PDIF over the AC-link connection, is it
> possible that the SiS7012 can do this also?

It plays no role for SIS7012 but only for ICH4 or later.
ICH4 or later chip has a dedicated DMA for SPDIF output, and it's
found that some boards don't use this but just transmit through the
normal DMA.  SIS7012 may have similar thing but who knows :)


Takashi


More information about the Alsa-devel mailing list