ALC Chips, now Realtek...

ALC Chips, now Realtek...

[Christoph Sassenberg]

Hi,


on my Epox 8K3A, there is a VT8233 together with an ALC201A Codec,
which does not work, as far I could figure out.
On Realtek HP I found as a Linux driver for that codec a modified
version of alsa-driver-0.5.11.

<-- snip from a97_codec.c -->

//====== added by hou 01/15/02
//      {       0x414c4710,     "ALC200/200P"			},
        {       0x414c4320,     "ALC100/100P"			},
        {       0x414c4710,     "ALC200"              		},
        {       0x414c4711,     "ALC201"       			},
        {       0x414c4712,     "ALC201A"                       },
  	{	0x414c4713,	"ALC201-G"			},
	{	0x414c4720,	"ALC650"			},
        {       0x414c4721,     "ALC650-D"   			},
 	{	0x414c4730,	"ALC101"			},
        {       0x414c4740,     "ALC202A-A"			},
        {       0x414c4741,     "ALC202-B"			},
        {       0x414c4742,     "ALC202A-C"			},
        {       0x414c4750,     "ALC250"          		},


and later on...

//====  added by hou 01/15/02   
	reg = snd_ac97_read(ac97, AC97_SIGMATEL_DAC2INVERT);
//      printk("id 0x%8x, ext 0x%x.\n", ac97->id, reg);
 	
        switch(ac97->id & 0xfffffff0) {
	case 0x414c4320:
 	case 0x414c4730:
	case 0x414c4750:
  	 	ac97->id = ac97->id & 0xfffffff0;
	        break;
   	case 0x414c4710:
		if ((reg & 0x0f) == 0)    
                	ac97->id = 0x414c4710;
        	else if ((reg & 0x0ff) == 0x11)
                        ac97->id = 0x414c4711;
		else if ((reg & 0x0ff) == 0x13)
                        ac97->id = 0x414c4712;
			        else if ((reg & 0x0ff) == 0x16)
 	                ac97->id = 0x414c4713;
	        else
                        ac97->id = 0x414c4710;
                break;  
 	case 0x414c4720:
                if (((reg & 0x0f) > 0) && ((reg & 0x0f) < 4))
                        ac97->id = 0x414c4720;
	        else if (((reg & 0x0f) > 3) && ((reg & 0x0f) < 8))
                        ac97->id = 0x414c4721;


As there are now these "bitmasks" in new ac97_codec.c, these chips can
be identified (as a start)...

Question: Is anybody working on that ALC stuff?


Regards,

	Sassi




_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

Re: ALC Chips, now Realtek...

[Sundance]

From: Christoph Sassenberg <sassi@sforce.org>

> Question: Is anybody working on that ALC stuff?

Apparently not. However, according to the sources of the alsa-driver-0.5.11 
thing from Realtek, it is kind of 'standard' as far as AC97 (or AC'97, I 
don't know -- there seems to be a subtle difference) is concerned, from what 
I can tell, so patching the current AC97 sources to get it to work shouldn't 
be /too/ difficult. Provided that you know /what/ to patch exactly. Which I 
don't, unfortunately (if one of the admirable gurus here were kind enough as 
to point us developper wannabees to some crash course to chip sound 
programming and ALSA 0.9, maybe... :)).

However, given VIA's recent messages to the list, I'd say I'm confident that 
support for VIA's latest southbridges (VT8233A et al) and the underlying 
chips shouldn't be too much of a long-term problem. Stay put, stay confident! 
It's great to see companies open up to the open source development way of 
thinking.

BTW, are you sure that your motherboard's southbridge is really a VT8233, and 
not a VT8233A? I have a gut feeling (based on little to no factual evidence, 
note) that our problems with recent VIA-based motherboards lie with the 
southbridge (VT8233A) and not the underlying sound chip (ALC<whatever>). Just 
an idea anyway.

-- S.

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm