Re: S/PDIF on AD1980 patch

Re: S/PDIF on AD1980 patch

[Jaroslaw Sobierski]

>> 
>> Here's the patch I promised. I had some trouble compiling the CVS version
>> (not the drivers but libs, still don't know why), but I supplemented with
>[...]
>
>Send us unified diff, please. It's more readable to verify the contents.
>

Will do. Once I get home :-). 
I thought since I'm only adding lines anyway it's more compact, but you're
right, it's easier to see it in context.

Another question though. I still cannot get the AC3 pass-through to work.
I assume the spdif source must be set to AC-Link (which is hw-reset default 
anyway), and I figure all other stuff should be set by alsa (like Category
Code, etc.). I have no problem with AC3 on emu10k1, so I guess mplayer is
requesting correct stream params from alsa. Yet on AC97 I can't get it to 
work (amp keeps indicating a PCM stream). Any suggestions what to look for?

--------------
Fycio (J.Sobierski)
 fycio@gucio.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: S/PDIF on AD1980 patch

[Takashi Iwai]

At Mon, 17 Feb 2003 08:01:27 -0800,
Jaroslaw Sobierski wrote:
> 
> 
> Another question though. I still cannot get the AC3 pass-through to work.
> I assume the spdif source must be set to AC-Link (which is hw-reset default 
> anyway), and I figure all other stuff should be set by alsa (like Category
> Code, etc.). I have no problem with AC3 on emu10k1, so I guess mplayer is
> requesting correct stream params from alsa. Yet on AC97 I can't get it to 
> work (amp keeps indicating a PCM stream). Any suggestions what to look for?

hmm.. ICH4 has a separate SPDIF channel and it looks like we don't use
this properly.  that is, SPDIF is routed via the normal slot 3/4.
perhaps we should route the spdif via slot 10/11 (in GLOB_CNT bit
30:31 to 1:1), and set SPSA to the corresponding value.
the definition of iec958 in ICH.conf should be rewritten, too...

anyway,  can you check whether the register 0x3a is set correctly when
mplayer tries to play ac3?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: S/PDIF on AD1980 patch

[Jaroslaw Sobierski]

Quoting Takashi Iwai <tiwai@suse.de>:

> At Mon, 17 Feb 2003 08:01:27 -0800,
> Jaroslaw Sobierski wrote:
> > 
> > 
> > Another question though. I still cannot get the AC3 pass-through to work.
> > I assume the spdif source must be set to AC-Link (which is hw-reset default
> 
> > anyway), and I figure all other stuff should be set by alsa (like
> Category
> > Code, etc.). I have no problem with AC3 on emu10k1, so I guess mplayer is
> > requesting correct stream params from alsa. Yet on AC97 I can't get it to
> 
> > work (amp keeps indicating a PCM stream). Any suggestions what to look
> for?
> 
> hmm.. ICH4 has a separate SPDIF channel and it looks like we don't use
> this properly.  that is, SPDIF is routed via the normal slot 3/4.
> perhaps we should route the spdif via slot 10/11 (in GLOB_CNT bit
> 30:31 to 1:1), and set SPSA to the corresponding value.
> the definition of iec958 in ICH.conf should be rewritten, too...
The default configuration for ad1980 is to use slots 7/8. 3/4 is not
the best choice since the DACs are set to this by default. I don't
think ICH4 has anything to do with this, I downloaded the specs a while
ago only to realize that it just gives you access to the ac97 regs and
that's it. There's practically nothing to configure on the south bridge
itself.

> 
> anyway,  can you check whether the register 0x3a is set correctly when
> mplayer tries to play ac3?
> 
Yes and no :-). I dumped all ac97 regs from /proc and was going to send
you teh list, but they did not change at all between PCM and ac3. I later
discovered, quite by accident, that for some reason ac3 is never routed
to the ac97 codec - when I choose the hwac3 option the stream always
goes to emu10k1 (and plays correctly over its spdif), even though I 
explicitly specify "hw:1". I have to try unloading the modules for emu and 
see what happens then. But this seems anyway a bug. Unless the ICH driver
declares no possibilty to create open ac3 stream and alsa falls back on
the default card? 

--------------
Fycio (J.Sobierski)
 fycio@gucio.com


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: S/PDIF on AD1980 patch

[Takashi Iwai]

At Thu, 20 Feb 2003 01:01:52 -0800,
Jaroslaw Sobierski wrote:
> 
> Quoting Takashi Iwai <tiwai@suse.de>:
> 
> > At Mon, 17 Feb 2003 08:01:27 -0800,
> > Jaroslaw Sobierski wrote:
> > > 
> > > 
> > > Another question though. I still cannot get the AC3 pass-through to work.
> > > I assume the spdif source must be set to AC-Link (which is hw-reset default
> > 
> > > anyway), and I figure all other stuff should be set by alsa (like
> > Category
> > > Code, etc.). I have no problem with AC3 on emu10k1, so I guess mplayer is
> > > requesting correct stream params from alsa. Yet on AC97 I can't get it to
> > 
> > > work (amp keeps indicating a PCM stream). Any suggestions what to look
> > for?
> > 
> > hmm.. ICH4 has a separate SPDIF channel and it looks like we don't use
> > this properly.  that is, SPDIF is routed via the normal slot 3/4.
> > perhaps we should route the spdif via slot 10/11 (in GLOB_CNT bit
> > 30:31 to 1:1), and set SPSA to the corresponding value.
> > the definition of iec958 in ICH.conf should be rewritten, too...
> The default configuration for ad1980 is to use slots 7/8. 3/4 is not
> the best choice since the DACs are set to this by default. I don't
> think ICH4 has anything to do with this, I downloaded the specs a while
> ago only to realize that it just gives you access to the ac97 regs and
> that's it.

no, as mentioned above, ICH4 has the configuration of SPDIF out slots
via GLOB_CNT bits 30:31.  please check these bits.

> There's practically nothing to configure on the south bridge itself.
> 
> > 
> > anyway,  can you check whether the register 0x3a is set correctly when
> > mplayer tries to play ac3?
> > 
> Yes and no :-). I dumped all ac97 regs from /proc and was going to send
> you teh list, but they did not change at all between PCM and ac3. I later
> discovered, quite by accident, that for some reason ac3 is never routed
> to the ac97 codec - when I choose the hwac3 option the stream always
> goes to emu10k1 (and plays correctly over its spdif), even though I 
> explicitly specify "hw:1". I have to try unloading the modules for emu and 
> see what happens then. But this seems anyway a bug. Unless the ICH driver
> declares no possibilty to create open ac3 stream and alsa falls back on
> the default card? 

can you try ac3dec in alsa-tools (with -C option).
if it works, then it's a bug of mplayer.  mplayer should access
"spdif" or "iec958" as the pcm name.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: S/PDIF on AD1980 patch

[Jaroslaw Sobierski]

Quoting Takashi Iwai <tiwai@suse.de>:

> > > hmm.. ICH4 has a separate SPDIF channel and it looks like we don't use
> > > this properly.  that is, SPDIF is routed via the normal slot 3/4.
> > > perhaps we should route the spdif via slot 10/11 (in GLOB_CNT bit
> > > 30:31 to 1:1), and set SPSA to the corresponding value.
> > > the definition of iec958 in ICH.conf should be rewritten, too...
> > The default configuration for ad1980 is to use slots 7/8. 3/4 is not
> > the best choice since the DACs are set to this by default. I don't
> > think ICH4 has anything to do with this, I downloaded the specs a while
> > ago only to realize that it just gives you access to the ac97 regs and
> > that's it.
> 
> no, as mentioned above, ICH4 has the configuration of SPDIF out slots
> via GLOB_CNT bits 30:31.  please check these bits.

You're absoultely right (of course). I didn't get that far in the ICH4 docs,
I thought the ac97 chapter covers it all :-).


> 
> > There's practically nothing to configure on the south bridge itself.
> > 
> > > 
> > > anyway,  can you check whether the register 0x3a is set correctly when
> > > mplayer tries to play ac3?
> > > 
> > Yes and no :-). I dumped all ac97 regs from /proc and was going to send
> > you teh list, but they did not change at all between PCM and ac3. I later
> > discovered, quite by accident, that for some reason ac3 is never routed
> > to the ac97 codec - when I choose the hwac3 option the stream always
> > goes to emu10k1 (and plays correctly over its spdif), even though I 
> > explicitly specify "hw:1". I have to try unloading the modules for emu and
> 
> > see what happens then. But this seems anyway a bug. Unless the ICH driver
> > declares no possibilty to create open ac3 stream and alsa falls back on
> > the default card? 
> 
> can you try ac3dec in alsa-tools (with -C option).
> if it works, then it's a bug of mplayer.  mplayer should access
> "spdif" or "iec958" as the pcm name.

Worked like a charm! No problem, on any of the two cards. So I guess I have
to start patching mplayer now ;-) (which I was gonna do eventually anyway,
since it doesn't handle dts streams correctly).

Thanks a lot for all your help guys! You've greatly help me enjoy my
audio experience on Linux.

Fycio. 

--------------
Fycio (J.Sobierski)
 fycio@gucio.com


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: S/PDIF on AD1980 patch

[Jaroslaw Sobierski]

OK, here is the unified diff. Two of them actually, i separated the 
different options for better clarity.

   Option 1 : The simple switch control 

Index: ac97_codec.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/ac97/ac97_codec.c,v
retrieving revision 1.66
diff -u -r1.66 ac97_codec.c
--- ac97_codec.c	17 Feb 2003 10:32:04 -0000	1.66
+++ ac97_codec.c	17 Feb 2003 19:25:50 -0000
@@ -1022,6 +1022,9 @@
 AD18XX_PCM_BITS("LFE Playback Volume", 2, 0, 31)
 };
 
+static const snd_kcontrol_new_t snd_ac97_ad1980_spdif_link =
+    AC97_SINGLE(SNDRV_CTL_NAME_IEC958("",PLAYBACK,NONE) "Link",
AC97_AD_SERIAL_CFG, 2, 1, 0);
+
 /*
  * ALC650
  */
@@ -1679,6 +1682,10 @@
 			if (ac97->id == AC97_ID_YMF753) {
 				for (idx = 0; idx < 3; idx++)
 					if ((err = snd_ctl_add(card,
snd_ac97_cnew(&snd_ac97_ymf753_controls_spdif[idx], ac97))) < 0)
+						return err;
+			}
+			if (ac97->id == AC97_ID_AD1980) {
+					if ((err = snd_ctl_add(card, snd_ac97_cnew(&snd_ac97_ad1980_spdif_link,
ac97))) < 0)
 						return err;
 			}
 			/* set default PCM S/PDIF params */
Index: ac97_id.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/ac97/ac97_id.h,v
retrieving revision 1.6
diff -u -r1.6 ac97_id.h
--- ac97_id.h	3 Dec 2002 17:46:53 -0000	1.6
+++ ac97_id.h	17 Feb 2003 19:25:50 -0000
@@ -31,6 +31,7 @@
 #define AC97_ID_AD1886		0x41445361
 #define AC97_ID_AD1887		0x41445362
 #define AC97_ID_AD1886A		0x41445363
+#define AC97_ID_AD1980 		0x41445370
 #define AC97_ID_TR28028		0x54524108
 #define AC97_ID_STAC9700	0x83847600
 #define AC97_ID_STAC9704	0x83847604
===================================================================

   Option 2 : The enumerated (more readable but more code) control

Index: ac97_codec.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/ac97/ac97_codec.c,v
retrieving revision 1.66
diff -u -r1.66 ac97_codec.c
--- ac97_codec.c	17 Feb 2003 10:32:04 -0000	1.66
+++ ac97_codec.c	17 Feb 2003 19:25:09 -0000
@@ -1022,6 +1022,49 @@
 AD18XX_PCM_BITS("LFE Playback Volume", 2, 0, 31)
 };
 
+static int snd_ac97_ad1980_spdif_source_info(snd_kcontrol_t *kcontrol,
snd_ctl_elem_info_t * uinfo)
+{
+	static char *texts[2] = { "AC-Link", "A/D Converter" };
+
+	uinfo->type = SNDRV_CTL_ELEM_TYPE_ENUMERATED;
+	uinfo->count = 1;
+	uinfo->value.enumerated.items = 2;
+	if (uinfo->value.enumerated.item > 1)
+		uinfo->value.enumerated.item = 1;
+	strcpy(uinfo->value.enumerated.name, texts[uinfo->value.enumerated.item]);
+	return 0;
+}
+
+static int snd_ac97_ad1980_spdif_source_get(snd_kcontrol_t * kcontrol,
snd_ctl_elem_value_t * ucontrol)
+{
+	ac97_t *ac97 = snd_kcontrol_chip(kcontrol);
+	unsigned short val;
+
+	val = ac97->regs[AC97_AD_SERIAL_CFG];
+	ucontrol->value.enumerated.item[0] = (val >> 2) & 1;
+	return 0;
+}
+
+static int snd_ac97_ad1980_spdif_source_put(snd_kcontrol_t * kcontrol,
snd_ctl_elem_value_t * ucontrol)
+{
+	ac97_t *ac97 = snd_kcontrol_chip(kcontrol);
+	unsigned short val;
+
+	if (ucontrol->value.enumerated.item[0] > 1)
+		return -EINVAL;
+	val = ucontrol->value.enumerated.item[0] << 2;
+	return snd_ac97_update_bits(ac97, AC97_AD_SERIAL_CFG, 0x0004, val);
+}
+
+static const snd_kcontrol_new_t snd_ac97_ad1980_spdif_source =
+	{
+		iface: SNDRV_CTL_ELEM_IFACE_MIXER,
+		name: SNDRV_CTL_NAME_IEC958("",PLAYBACK,NONE) "Source",
+		info: snd_ac97_ad1980_spdif_source_info,
+		get: snd_ac97_ad1980_spdif_source_get,
+		put: snd_ac97_ad1980_spdif_source_put,
+	};
+
 /*
  * ALC650
  */
@@ -1679,6 +1722,10 @@
 			if (ac97->id == AC97_ID_YMF753) {
 				for (idx = 0; idx < 3; idx++)
 					if ((err = snd_ctl_add(card,
snd_ac97_cnew(&snd_ac97_ymf753_controls_spdif[idx], ac97))) < 0)
+						return err;
+			}
+			if (ac97->id == AC97_ID_AD1980) {
+					if ((err = snd_ctl_add(card, snd_ac97_cnew(&snd_ac97_ad1980_spdif_source,
ac97))) < 0)
 						return err;
 			}
 			/* set default PCM S/PDIF params */
Index: ac97_id.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/ac97/ac97_id.h,v
retrieving revision 1.6
diff -u -r1.6 ac97_id.h
--- ac97_id.h	3 Dec 2002 17:46:53 -0000	1.6
+++ ac97_id.h	17 Feb 2003 19:25:09 -0000
@@ -31,6 +31,7 @@
 #define AC97_ID_AD1886		0x41445361
 #define AC97_ID_AD1887		0x41445362
 #define AC97_ID_AD1886A		0x41445363
+#define AC97_ID_AD1980 		0x41445370
 #define AC97_ID_TR28028		0x54524108
 #define AC97_ID_STAC9700	0x83847600
 #define AC97_ID_STAC9704	0x83847604
===================================================================

See previous post for details.

--------------
Fycio (J.Sobierski)
 fycio@gucio.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: S/PDIF on AD1980 patch

[Takashi Iwai]

At Mon, 17 Feb 2003 11:36:34 -0800,
Jaroslaw Sobierski wrote:
> 
> OK, here is the unified diff. Two of them actually, i separated the 
> different options for better clarity.
...
> 
>    Option 2 : The enumerated (more readable but more code) control

i took this.  clarity is better, isn't it?
(btw, you can change enum values via alsamixer, too.)

ok, i committed to cvs.  please check whether it works for you.


the changes for AD1981A/B are not done yet.
does anyone have this device?


thanks,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: S/PDIF on AD1980 patch

[Jaroslaw Sobierski]

Quoting Takashi Iwai <tiwai@suse.de>:

> At Mon, 17 Feb 2003 11:36:34 -0800,
> Jaroslaw Sobierski wrote:
> > 
> > OK, here is the unified diff. Two of them actually, i separated the 
> > different options for better clarity.
> ...
> > 
> >    Option 2 : The enumerated (more readable but more code) control
> 
> i took this.  clarity is better, isn't it?

By all means. 

> (btw, you can change enum values via alsamixer, too.)
Really? Well I assumed it would be possible but couldn't figure
out how. And the help feature didn't help much :-)

> 
> ok, i committed to cvs.  please check whether it works for you.
> 
I will this evening, had some network problems yesterday.

> 
> the changes for AD1981A/B are not done yet.
> does anyone have this device?
> 
I know 1981A is installed on a few boards with the 845 chipset,
mainly Fujitsu and AOpen, but probably others too.

Tha 1981B is harder to come by, maybe because it's newer, it's
mostly on Intel boards (with different flavors of the 845 chipset).

--------------
Fycio (J.Sobierski)
 fycio@gucio.com


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: S/PDIF on AD1980 patch

[Jaroslaw Sobierski]

Quoting Takashi Iwai <tiwai@suse.de>:

> At Mon, 17 Feb 2003 11:36:34 -0800,
> Jaroslaw Sobierski wrote:
> > 
> > OK, here is the unified diff. Two of them actually, i separated the 
> > different options for better clarity.
> ...
> > 
> >    Option 2 : The enumerated (more readable but more code) control
> 
> i took this.  clarity is better, isn't it?
> (btw, you can change enum values via alsamixer, too.)
> 
> ok, i committed to cvs.  please check whether it works for you.
> 

It does, I checked yesterday. 
Does anybody else have this chip to confirm?

--------------
Fycio (J.Sobierski)
 fycio@gucio.com


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

Re: S/PDIF on AD1980 patch

[Jaroslaw Sobierski]

Here's the patch I promised. I had some trouble compiling the CVS version
(not the drivers but libs, still don't know why), but I supplemented with
libs compiled from the tarball (rc7) and it worked. Anyway - I created two
controls - a simple switch ( the "Link" ) and an enum ("Source") first
was simple yet fully functional and had the adventage of being modifiable
via alsamixer, which an enum isn't. The second control is more elegant
(based on a similar control for the YMF753), but needs much more code
and cannot be used in alsamixer (or I don't know how to do it). Works
fine via amixer controls though. Anyway, it doesn't make sense to add
both (although they do work simultanously), so I leave it up to alsa
vetrans maintaining the CVS tree to decide which solution is better.

According to Analog Devices specs this patch should work for all 1980
series chips, namely 41445370 (ad1980-that's the one I test for),
41445371 (ad1980A) and 41445374 (ad1980B). But since I can't test the
other ones - I left it at that.


Index: ac97_codec.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/ac97/ac97_codec.c,v
retrieving revision 1.63
diff -r1.63 ac97_codec.c
1022a1023,1071
> static const snd_kcontrol_new_t snd_ac97_ad1980_spdif_link =
>     AC97_SINGLE(SNDRV_CTL_NAME_IEC958("",PLAYBACK,NONE) "Link",
AC97_AD_SERIAL_CFG, 2, 1, 0);
>
> static int snd_ac97_ad1980_spdif_source_info(snd_kcontrol_t *kcontrol,
snd_ctl_elem_info_t * uinfo)
> {
>       static char *texts[2] = { "AC-Link", "A/D Converter" };
>
>       uinfo->type = SNDRV_CTL_ELEM_TYPE_ENUMERATED;
>       uinfo->count = 1;
>       uinfo->value.enumerated.items = 2;
>       if (uinfo->value.enumerated.item > 1)
>               uinfo->value.enumerated.item = 1;
>       strcpy(uinfo->value.enumerated.name, texts[uinfo->value.enumerated.item]);
>       return 0;
> }
>
> static int snd_ac97_ad1980_spdif_source_get(snd_kcontrol_t * kcontrol,
snd_ctl_elem_value_t * ucontrol)
> {
>       ac97_t *ac97 = snd_kcontrol_chip(kcontrol);
>       unsigned short val;
>
>       val = ac97->regs[AC97_AD_SERIAL_CFG];
>       ucontrol->value.enumerated.item[0] = (val >> 2) & 1;
>       return 0;
> }
>
> static int snd_ac97_ad1980_spdif_source_put(snd_kcontrol_t * kcontrol,
snd_ctl_elem_value_t * ucontrol)
> {
>       ac97_t *ac97 = snd_kcontrol_chip(kcontrol);
>       unsigned short val;
>
>       if (ucontrol->value.enumerated.item[0] > 1)
>               return -EINVAL;
>       val = ucontrol->value.enumerated.item[0] << 2;
>       return snd_ac97_update_bits(ac97, AC97_AD_SERIAL_CFG, 0x0004, val);
> }
>
> static const snd_kcontrol_new_t snd_ac97_ad1980_spdif_source =
>       {
>               iface: SNDRV_CTL_ELEM_IFACE_MIXER,
>               name: SNDRV_CTL_NAME_IEC958("",PLAYBACK,NONE) "Source",
>               info: snd_ac97_ad1980_spdif_source_info,
>               get: snd_ac97_ad1980_spdif_source_get,
>               put: snd_ac97_ad1980_spdif_source_put,
>       };
>
>
>
>
1675a1725,1730
>                                               return err;
>                       }
>                       if (ac97->id == AC97_ID_AD1980) {
>                                       if ((err = snd_ctl_add(card,
snd_ac97_cnew(&snd_ac97_ad1980_spdif_link, ac                         97))) < 0)
>                                               return err;
>                                       if ((err = snd_ctl_add(card,
snd_ac97_cnew(&snd_ac97_ad1980_spdif_source,                          ac97))) < 0)
Index: ac97_id.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/ac97/ac97_id.h,v
retrieving revision 1.6
diff -r1.6 ac97_id.h
33a34
> #define AC97_ID_AD1980                0x41445370


--------------
Fycio (J.Sobierski)
 fycio@gucio.com


-------------------------------------------------------
This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your  SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en

Re: S/PDIF on AD1980 patch

[Jaroslav Kysela]

On Fri, 14 Feb 2003, Jaroslaw Sobierski wrote:

> 
> Here's the patch I promised. I had some trouble compiling the CVS version
> (not the drivers but libs, still don't know why), but I supplemented with
> libs compiled from the tarball (rc7) and it worked. Anyway - I created two
> controls - a simple switch ( the "Link" ) and an enum ("Source") first
> was simple yet fully functional and had the adventage of being modifiable
> via alsamixer, which an enum isn't. The second control is more elegant
> (based on a similar control for the YMF753), but needs much more code
> and cannot be used in alsamixer (or I don't know how to do it). Works
> fine via amixer controls though. Anyway, it doesn't make sense to add
> both (although they do work simultanously), so I leave it up to alsa
> vetrans maintaining the CVS tree to decide which solution is better.
> 
> According to Analog Devices specs this patch should work for all 1980
> series chips, namely 41445370 (ad1980-that's the one I test for),
> 41445371 (ad1980A) and 41445374 (ad1980B). But since I can't test the
> other ones - I left it at that.

Send us unified diff, please. It's more readable to verify the contents.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

S/PDIF on AD1980 patch

[Jaroslaw Sobierski]

Hi all,

I recently installed an Asus P4PE with built in AD1980 audio codec
(accessible through the ICH4 south bridge). The latest ALSA drivers
detected the chip and AC97 audio correctly even setting up the 
IEC958 controls. The problem is I still got no output on the external
S/PDIF module. 

I downloaded the specs from Analog Devices and found the register
responsible for this, modified the AC97 codec drivers to add a
control for the 3 flags specific to this chip (ie. outside of the ac97
specification) concerning the digital interface and managed to turn
it on. 

I would like to submit this modification so that others who may have
a similar setup can use it. So my question is : what's next? Who can
merge such patches to the CVS tree and what is the validation and/or
testing procedure? Or do I just mail the code to 'perex' and he takes
care of it?

I found similar patches for different chips with controls specific to
them, so I assume this is the accepted solution, although it would
also be possible simply initialize this register to the "on" value on
startup - since this is a dedicated digital output, not shared with 
lfe/center like on Creative's sound cards.

Jaroslaw Sobierski


--------------
Fycio (J.Sobierski)
 fycio@gucio.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: S/PDIF on AD1980 patch

[Takashi Iwai]

At Thu, 13 Feb 2003 03:19:02 -0800,
Jaroslaw Sobierski wrote:
> 
> 
> Hi all,
> 
> I recently installed an Asus P4PE with built in AD1980 audio codec
> (accessible through the ICH4 south bridge). The latest ALSA drivers
> detected the chip and AC97 audio correctly even setting up the 
> IEC958 controls. The problem is I still got no output on the external
> S/PDIF module. 
> 
> I downloaded the specs from Analog Devices and found the register
> responsible for this, modified the AC97 codec drivers to add a
> control for the 3 flags specific to this chip (ie. outside of the ac97
> specification) concerning the digital interface and managed to turn
> it on. 
> 
> I would like to submit this modification so that others who may have
> a similar setup can use it. So my question is : what's next? Who can
> merge such patches to the CVS tree and what is the validation and/or
> testing procedure? Or do I just mail the code to 'perex' and he takes
> care of it?

just send the patch to alsa-devel ML.  (or you can send to Jaroslav or
me directly, too, if you don't show the patch publicly :)
we'll review the patch and soon commit to cvs if it's ok.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf