Re: [Alsa-user] is this card supported by ALSA?

Re: [Alsa-user] is this card supported by ALSA?

[Rene Herman]

On 15-07-08 01:36, Landis McGauhey wrote:

It seems there's just a bit too much oddness going on. Takashi, you know 
more about ac97. Also bringing in alsa-devel...

> # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0=
> 
> 0-0/0: 0x76058384 F�S

Eep? A 0x83847605 would be a SigmaTel STAC9704. And:

[ ... ]

> # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0+regs=

[ ... ]

> 0:7c = 0000
> 0:7e = 8384

does't fit the above ID. Do we just have a crummy codec that needs delay 
between acceses somewhere or something?

Here full contents again:

> # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0=
> 
> 0-0/0: 0x76058384 F�S
> 
> PCI Subsys Vendor: 0x0000
> PCI Subsys Device: 0x0000
> 
> Capabilities     : -dedicated MIC PCM IN channel- -bass & treble-
> DAC resolution   : 16-bit
> ADC resolution   : 20-bit
> 3D enhancement   : Reserved 29
> 
> Current setup
> Mic gain         : +0dB [+20dB]
> POP path         : post 3D
> Sim. stereo      : off
> 3D enhancement   : off
> Loudness         : on
> Mono output      : MIX
> Mic select       : Mic2
> ADC/DAC loopback : off
> 
> # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0+regs=
> 
> 0:00 = 0000
> 0:02 = 0140
> 0:04 = 8909
> 0:06 = 8000
> 0:08 = 8009
> 0:0a = ffff
> 0:0c = 150b
> 0:0e = 801f
> 0:10 = 805f
> 0:12 = 9515
> 0:14 = 9212
> 0:16 = 9f1f
> 0:18 = 9f1f
> 0:1a = 9010
> 0:1c = 0000
> 0:1e = 0000
> 0:20 = 0000
> 0:22 = 0000
> 0:24 = 0000
> 0:26 = 0000
> 0:28 = 000f
> 0:2a = ffff
> 0:2c = ffff
> 0:2e = ffff
> 0:30 = ffff
> 0:32 = ffff
> 0:34 = ffff
> 0:36 = ffff
> 0:38 = ffff
> 0:3a = ffff
> 0:3c = ffff
> 0:3e = ffff
> 0:40 = ffff
> 0:42 = ffff
> 0:44 = ffff
> 0:46 = ffff
> 0:48 = ffff
> 0:4a = ffff
> 0:4c = ffff
> 0:4e = ffff
> 0:50 = ffff
> 0:52 = ffff
> 0:54 = ffff
> 0:56 = ffff
> 0:58 = ffff
> 0:5a = 0000
> 0:5c = 0000
> 0:5e = 0000
> 0:60 = 0000
> 0:62 = 0000
> 0:64 = 0000
> 0:66 = 0000
> 0:68 = 0000
> 0:6a = 0000
> 0:6c = 0000
> 0:6e = 0000
> 0:70 = 0000
> 0:72 = 0000
> 0:74 = 0000
> 0:76 = 0000
> 0:78 = 0000
> 0:7a = 0000
> 0:7c = 0000
> 0:7e = 8384

Rene.

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

Re: is this card supported by ALSA?

[Landis McGauhey]

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




> Date: Tue, 15 Jul 2008 02:11:41 +0200
> From: rene.herman@keyaccess.nl
> To: b3zdomny@hotmail.com
> CC: alsa-user@lists.sourceforge.net; tiwai@suse.de; alsa-devel@alsa-project.org
> Subject: Re: [Alsa-user] is this card supported by ALSA?
> 
<snip>

Thanks, Rene, especially for bringing in Takashi and alsa-devel.  I'm off to bed and will check my mail again in about eight hours.  Please don't hesitate to let me know if there's any more output I can post.  I appreciate the help and am sure together we'll find the ALSA solution.

best regards,

Landis

_________________________________________________________________
Making the world a better place one message at a time.
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_BetterPlace

[-- Attachment #1.2: Type: text/html, Size: 1024 bytes --]

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: is this card supported by ALSA?

[Takashi Iwai]

At Tue, 15 Jul 2008 02:11:41 +0200,
Rene Herman wrote:
> 
> On 15-07-08 01:36, Landis McGauhey wrote:
> 
> It seems there's just a bit too much oddness going on. Takashi, you know 
> more about ac97. Also bringing in alsa-devel...
> 
> > # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0=
> > 
> > 0-0/0: 0x76058384 F�S
> 
> Eep? A 0x83847605 would be a SigmaTel STAC9704. And:
> 
> [ ... ]
> 
> > # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0+regs=
> 
> [ ... ]
> 
> > 0:7c = 0000
> > 0:7e = 8384
> 
> does't fit the above ID. Do we just have a crummy codec that needs delay 
> between acceses somewhere or something?

I guess it's rather the controller code.  Will check this later.


thanks,

Takashi

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: is this card supported by ALSA?

[Landis McGauhey]

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





> Date: Tue, 15 Jul 2008 15:11:09 +0200
> From: tiwai@suse.de
> To: rene.herman@keyaccess.nl
> CC: b3zdomny@hotmail.com; alsa-user@lists.sourceforge.net; alsa-devel@alsa-project.org
> Subject: Re: [Alsa-user] is this card supported by ALSA?
> 
> At Tue, 15 Jul 2008 02:11:41 +0200,
> Rene Herman wrote:
> > 
> > On 15-07-08 01:36, Landis McGauhey wrote:
> > 
> > It seems there's just a bit too much oddness going on. Takashi, you know 
> > more about ac97. Also bringing in alsa-devel...
> > 
> > > # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0=
> > > 
> > > 0-0/0: 0x76058384 F�S
> > 
> > Eep? A 0x83847605 would be a SigmaTel STAC9704. And:
> > 
> > [ ... ]
> > 
> > > # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0+regs=
> > 
> > [ ... ]
> > 
> > > 0:7c = 0000
> > > 0:7e = 8384
> > 
> > does't fit the above ID. Do we just have a crummy codec that needs delay 
> > between acceses somewhere or something?
> 
> I guess it's rather the controller code.  Will check this later.
> 
> 
> thanks,
> 
> Takashi


Thanks, Takashi.

best regards from Northern Calfornia USA,

Landis

_________________________________________________________________
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008

[-- Attachment #1.2: Type: text/html, Size: 1838 bytes --]

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: is this card supported by ALSA?

[Takashi Iwai]

At Tue, 15 Jul 2008 15:11:09 +0200,
I wrote:
> 
> At Tue, 15 Jul 2008 02:11:41 +0200,
> Rene Herman wrote:
> > 
> > On 15-07-08 01:36, Landis McGauhey wrote:
> > 
> > It seems there's just a bit too much oddness going on. Takashi, you know 
> > more about ac97. Also bringing in alsa-devel...
> > 
> > > # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0=
> > > 
> > > 0-0/0: 0x76058384 F�S
> > 
> > Eep? A 0x83847605 would be a SigmaTel STAC9704. And:
> > 
> > [ ... ]
> > 
> > > # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0+regs=
> > 
> > [ ... ]
> > 
> > > 0:7c = 0000
> > > 0:7e = 8384
> > 
> > does't fit the above ID. Do we just have a crummy codec that needs delay 
> > between acceses somewhere or something?
> 
> I guess it's rather the controller code.  Will check this later.

The below is a patch to improve the codec access routines in a bit
more robust way (and clean-ups, too).  Give it a try.


Takashi

---
diff --git a/sound/pci/ens1370.c b/sound/pci/ens1370.c
index fbf1124..5c962b6 100644
--- a/sound/pci/ens1370.c
+++ b/sound/pci/ens1370.c
@@ -461,8 +461,6 @@ MODULE_DEVICE_TABLE(pci, snd_audiopci_ids);
  *  constants
  */
 
-#define POLL_COUNT	0xa000
-
 #ifdef CHIP1370
 static unsigned int snd_es1370_fixed_rates[] =
 	{5512, 11025, 22050, 44100};
@@ -514,14 +512,16 @@ static const unsigned int snd_ensoniq_sample_shift[] =
 
 static unsigned int snd_es1371_wait_src_ready(struct ensoniq * ensoniq)
 {
-	unsigned int t, r = 0;
+	unsigned int r = 0;
+	unsigned long end_time;
 
-	for (t = 0; t < POLL_COUNT; t++) {
+	end_time = jiffies + msecs_to_jiffies(100);
+	do {
 		r = inl(ES_REG(ensoniq, 1371_SMPRATE));
 		if ((r & ES_1371_SRC_RAM_BUSY) == 0)
 			return r;
-		cond_resched();
-	}
+		schedule_timeout_uninterruptible(1);
+	} while (time_after_eq(end_time, jiffies));
 	snd_printk(KERN_ERR "wait source ready timeout 0x%lx [0x%x]\n",
 		   ES_REG(ensoniq, 1371_SMPRATE), r);
 	return 0;
@@ -529,7 +529,7 @@ static unsigned int snd_es1371_wait_src_ready(struct ensoniq * ensoniq)
 
 static unsigned int snd_es1371_src_read(struct ensoniq * ensoniq, unsigned short reg)
 {
-	unsigned int temp, i, orig, r;
+	unsigned int temp, orig, r;
 
 	/* wait for ready */
 	temp = orig = snd_es1371_wait_src_ready(ensoniq);
@@ -545,11 +545,13 @@ static unsigned int snd_es1371_src_read(struct ensoniq * ensoniq, unsigned short
 	
 	if ((temp & 0x00870000) != 0x00010000) {
 		/* wait for the right state */
-		for (i = 0; i < POLL_COUNT; i++) {
+		unsigned long end_time = jiffies + msecs_to_jiffies(100);
+		do {
 			temp = inl(ES_REG(ensoniq, 1371_SMPRATE));
 			if ((temp & 0x00870000) == 0x00010000)
 				break;
-		}
+			schedule_timeout_uninterruptible(1);
+		} while (time_after_eq(end_time, jiffies));
 	}
 
 	/* hide the state bits */	
@@ -602,104 +604,90 @@ static void snd_es1370_codec_write(struct snd_ak4531 *ak4531,
 
 #ifdef CHIP1371
 
+static int _es1371_wait_wip(struct ensoniq *ensoniq)
+{
+	unsigned long end_time;
+
+	end_time = jiffies + msecs_to_jiffies(100);
+	do {
+		if (!(inl(ES_REG(ensoniq, 1371_CODEC)) & ES_1371_CODEC_WIP))
+			return 0;
+	} while (time_after_eq(end_time, jiffies));
+	snd_printk(KERN_ERR "codec wait timeout, status = 0x%x\n",
+		   inl(ES_REG(ensoniq, 1371_CODEC)));
+	return -EINVAL;
+}
+
+static void _es1371_codec_write(struct ensoniq *ensoniq,
+				unsigned int val)
+{
+	unsigned int x;
+	unsigned long end_time;
+
+	_es1371_wait_wip(ensoniq);
+	/* save the current state for latter */
+	x = snd_es1371_wait_src_ready(ensoniq);
+	outl((x & (ES_1371_SRC_DISABLE | ES_1371_DIS_P1 |
+		   ES_1371_DIS_P2 | ES_1371_DIS_R1)) | 0x00010000,
+	     ES_REG(ensoniq, 1371_SMPRATE));
+	/* wait for not busy (state 0) first to avoid
+	   transition states */
+	end_time = jiffies + msecs_to_jiffies(100);
+	do {
+		if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
+		    0x00000000)
+			break;
+	} while (time_after_eq(end_time, jiffies));
+	/* wait for a SAFE time to write addr/data and then do it, dammit */
+	end_time = jiffies + msecs_to_jiffies(100);
+	do {
+		if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
+		    0x00010000)
+			break;
+	} while (time_after_eq(end_time, jiffies));
+	outl(val, ES_REG(ensoniq, 1371_CODEC));
+	/* restore SRC reg */
+	snd_es1371_wait_src_ready(ensoniq);
+	outl(x, ES_REG(ensoniq, 1371_SMPRATE));
+}
+
 static void snd_es1371_codec_write(struct snd_ac97 *ac97,
 				   unsigned short reg, unsigned short val)
 {
 	struct ensoniq *ensoniq = ac97->private_data;
-	unsigned int t, x;
 
 	mutex_lock(&ensoniq->src_mutex);
-	for (t = 0; t < POLL_COUNT; t++) {
-		if (!(inl(ES_REG(ensoniq, 1371_CODEC)) & ES_1371_CODEC_WIP)) {
-			/* save the current state for latter */
-			x = snd_es1371_wait_src_ready(ensoniq);
-			outl((x & (ES_1371_SRC_DISABLE | ES_1371_DIS_P1 |
-			           ES_1371_DIS_P2 | ES_1371_DIS_R1)) | 0x00010000,
-			     ES_REG(ensoniq, 1371_SMPRATE));
-			/* wait for not busy (state 0) first to avoid
-			   transition states */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
-				    0x00000000)
-					break;
-			}
-			/* wait for a SAFE time to write addr/data and then do it, dammit */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
-				    0x00010000)
-					break;
-			}
-			outl(ES_1371_CODEC_WRITE(reg, val), ES_REG(ensoniq, 1371_CODEC));
-			/* restore SRC reg */
-			snd_es1371_wait_src_ready(ensoniq);
-			outl(x, ES_REG(ensoniq, 1371_SMPRATE));
-			mutex_unlock(&ensoniq->src_mutex);
-			return;
-		}
-	}
+	_es1371_codec_write(ensoniq, ES_1371_CODEC_WRITE(reg, val));
 	mutex_unlock(&ensoniq->src_mutex);
-	snd_printk(KERN_ERR "codec write timeout at 0x%lx [0x%x]\n",
-		   ES_REG(ensoniq, 1371_CODEC), inl(ES_REG(ensoniq, 1371_CODEC)));
 }
 
 static unsigned short snd_es1371_codec_read(struct snd_ac97 *ac97,
 					    unsigned short reg)
 {
 	struct ensoniq *ensoniq = ac97->private_data;
-	unsigned int t, x, fail = 0;
+	unsigned int fail;
+	unsigned long end_time;
 
-      __again:
 	mutex_lock(&ensoniq->src_mutex);
-	for (t = 0; t < POLL_COUNT; t++) {
-		if (!(inl(ES_REG(ensoniq, 1371_CODEC)) & ES_1371_CODEC_WIP)) {
-			/* save the current state for latter */
-			x = snd_es1371_wait_src_ready(ensoniq);
-			outl((x & (ES_1371_SRC_DISABLE | ES_1371_DIS_P1 |
-			           ES_1371_DIS_P2 | ES_1371_DIS_R1)) | 0x00010000,
-			     ES_REG(ensoniq, 1371_SMPRATE));
-			/* wait for not busy (state 0) first to avoid
-			   transition states */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
-				    0x00000000)
-					break;
+	for (fail = 0; fail < 10; fail++) {
+		_es1371_codec_write(ensoniq, ES_1371_CODEC_READS(reg));
+		/* wait for WIP again */
+		_es1371_wait_wip(ensoniq);
+		/* now wait for the stinkin' data (RDY) */
+		end_time = jiffies + msecs_to_jiffies(100);
+		do {
+			unsigned int x = inl(ES_REG(ensoniq, 1371_CODEC));
+			if (x & ES_1371_CODEC_RDY) {
+				mutex_unlock(&ensoniq->src_mutex);
+				return ES_1371_CODEC_READ(x);
 			}
-			/* wait for a SAFE time to write addr/data and then do it, dammit */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
-				    0x00010000)
-					break;
-			}
-			outl(ES_1371_CODEC_READS(reg), ES_REG(ensoniq, 1371_CODEC));
-			/* restore SRC reg */
-			snd_es1371_wait_src_ready(ensoniq);
-			outl(x, ES_REG(ensoniq, 1371_SMPRATE));
-			/* wait for WIP again */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if (!(inl(ES_REG(ensoniq, 1371_CODEC)) & ES_1371_CODEC_WIP))
-					break;		
-			}
-			/* now wait for the stinkin' data (RDY) */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if ((x = inl(ES_REG(ensoniq, 1371_CODEC))) & ES_1371_CODEC_RDY) {
-					mutex_unlock(&ensoniq->src_mutex);
-					return ES_1371_CODEC_READ(x);
-				}
-			}
-			mutex_unlock(&ensoniq->src_mutex);
-			if (++fail > 10) {
-				snd_printk(KERN_ERR "codec read timeout (final) "
-					   "at 0x%lx, reg = 0x%x [0x%x]\n",
-					   ES_REG(ensoniq, 1371_CODEC), reg,
-					   inl(ES_REG(ensoniq, 1371_CODEC)));
-				return 0;
-			}
-			goto __again;
-		}
+		} while (time_after_eq(end_time, jiffies));
 	}
+	snd_printk(KERN_ERR "codec read timeout (final) "
+		   "at 0x%lx, reg = 0x%x [0x%x]\n",
+		   ES_REG(ensoniq, 1371_CODEC), reg,
+		   inl(ES_REG(ensoniq, 1371_CODEC)));
 	mutex_unlock(&ensoniq->src_mutex);
-	snd_printk(KERN_ERR "es1371: codec read timeout at 0x%lx [0x%x]\n",
-		   ES_REG(ensoniq, 1371_CODEC), inl(ES_REG(ensoniq, 1371_CODEC)));
 	return 0;
 }
 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] is this card supported by ALSA?

[Rene Herman]

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

On 15-07-08 16:19, Takashi Iwai wrote:

> The below is a patch to improve the codec access routines in a bit
> more robust way (and clean-ups, too).  Give it a try.

Thank you for taking this...

Landis, if it's easier for you due to webmail stuff, I'm attaching the 
patch to this message so that it might be easier for you to save it 
(Takashi posted it "inline" in the message).

The way to use this is very similar to what you did for the OSS driver 
patch. You save this somewhere, then from the root of the source tree 
(from /usr/src/linux-2.6.25.9 it was...) you do

# patch -p1 --dry-run < /some/where/ens1371-ac97.diff

and upon seeing that complete without errors, without the --dry-run:

# patch -p1 --dry-run < /some/where/ens1371-ac97.diff

You then recompile the kernel with "make" (which should now only 
recompile the snd-ens1371 driver) and do a "make modules_install" after 
it finishes.

Then, make sure no old driver for the card is loaded:

# modprobe -r snd-ens1371
# modprobe -r es1371

and load the new one:

# modprobe snd-ens1371

then up and unmute volumes in alsamixer again and try if you have sound 
with "speaker-test" or "aplay foo.wav".

If you do, you should blacklist the now installed OSS es1371 driver (add 
"blacklist es1371" to /etc/modprobe.d/blacklist) and make sure 
snd-ens1371 is no longer blacklisted. If all's well, working sound 
should then survive a reboot (and a future kernel would include the fix 
autonmatically so things just work out of the box).

Rene.

[-- Attachment #2: ens1371-ac97.diff --]
[-- Type: text/plain, Size: 7633 bytes --]

diff --git a/sound/pci/ens1370.c b/sound/pci/ens1370.c
index 72d85a5..cd74fb2 100644
--- a/sound/pci/ens1370.c
+++ b/sound/pci/ens1370.c
@@ -461,8 +461,6 @@ MODULE_DEVICE_TABLE(pci, snd_audiopci_ids);
  *  constants
  */
 
-#define POLL_COUNT	0xa000
-
 #ifdef CHIP1370
 static unsigned int snd_es1370_fixed_rates[] =
 	{5512, 11025, 22050, 44100};
@@ -514,14 +512,16 @@ static const unsigned int snd_ensoniq_sample_shift[] =
 
 static unsigned int snd_es1371_wait_src_ready(struct ensoniq * ensoniq)
 {
-	unsigned int t, r = 0;
+	unsigned int r = 0;
+	unsigned long end_time;
 
-	for (t = 0; t < POLL_COUNT; t++) {
+	end_time = jiffies + msecs_to_jiffies(100);
+	do {
 		r = inl(ES_REG(ensoniq, 1371_SMPRATE));
 		if ((r & ES_1371_SRC_RAM_BUSY) == 0)
 			return r;
-		cond_resched();
-	}
+		schedule_timeout_uninterruptible(1);
+	} while (time_after_eq(end_time, jiffies));
 	snd_printk(KERN_ERR "wait source ready timeout 0x%lx [0x%x]\n",
 		   ES_REG(ensoniq, 1371_SMPRATE), r);
 	return 0;
@@ -529,7 +529,7 @@ static unsigned int snd_es1371_wait_src_ready(struct ensoniq * ensoniq)
 
 static unsigned int snd_es1371_src_read(struct ensoniq * ensoniq, unsigned short reg)
 {
-	unsigned int temp, i, orig, r;
+	unsigned int temp, orig, r;
 
 	/* wait for ready */
 	temp = orig = snd_es1371_wait_src_ready(ensoniq);
@@ -545,11 +545,13 @@ static unsigned int snd_es1371_src_read(struct ensoniq * ensoniq, unsigned short
 	
 	if ((temp & 0x00870000) != 0x00010000) {
 		/* wait for the right state */
-		for (i = 0; i < POLL_COUNT; i++) {
+		unsigned long end_time = jiffies + msecs_to_jiffies(100);
+		do {
 			temp = inl(ES_REG(ensoniq, 1371_SMPRATE));
 			if ((temp & 0x00870000) == 0x00010000)
 				break;
-		}
+			schedule_timeout_uninterruptible(1);
+		} while (time_after_eq(end_time, jiffies));
 	}
 
 	/* hide the state bits */	
@@ -602,104 +604,90 @@ static void snd_es1370_codec_write(struct snd_ak4531 *ak4531,
 
 #ifdef CHIP1371
 
+static int _es1371_wait_wip(struct ensoniq *ensoniq)
+{
+	unsigned long end_time;
+
+	end_time = jiffies + msecs_to_jiffies(100);
+	do {
+		if (!(inl(ES_REG(ensoniq, 1371_CODEC)) & ES_1371_CODEC_WIP))
+			return 0;
+	} while (time_after_eq(end_time, jiffies));
+	snd_printk(KERN_ERR "codec wait timeout, status = 0x%x\n",
+		   inl(ES_REG(ensoniq, 1371_CODEC)));
+	return -EINVAL;
+}
+
+static void _es1371_codec_write(struct ensoniq *ensoniq,
+				unsigned int val)
+{
+	unsigned int x;
+	unsigned long end_time;
+
+	_es1371_wait_wip(ensoniq);
+	/* save the current state for latter */
+	x = snd_es1371_wait_src_ready(ensoniq);
+	outl((x & (ES_1371_SRC_DISABLE | ES_1371_DIS_P1 |
+		   ES_1371_DIS_P2 | ES_1371_DIS_R1)) | 0x00010000,
+	     ES_REG(ensoniq, 1371_SMPRATE));
+	/* wait for not busy (state 0) first to avoid
+	   transition states */
+	end_time = jiffies + msecs_to_jiffies(100);
+	do {
+		if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
+		    0x00000000)
+			break;
+	} while (time_after_eq(end_time, jiffies));
+	/* wait for a SAFE time to write addr/data and then do it, dammit */
+	end_time = jiffies + msecs_to_jiffies(100);
+	do {
+		if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
+		    0x00010000)
+			break;
+	} while (time_after_eq(end_time, jiffies));
+	outl(val, ES_REG(ensoniq, 1371_CODEC));
+	/* restore SRC reg */
+	snd_es1371_wait_src_ready(ensoniq);
+	outl(x, ES_REG(ensoniq, 1371_SMPRATE));
+}
+
 static void snd_es1371_codec_write(struct snd_ac97 *ac97,
 				   unsigned short reg, unsigned short val)
 {
 	struct ensoniq *ensoniq = ac97->private_data;
-	unsigned int t, x;
 
 	mutex_lock(&ensoniq->src_mutex);
-	for (t = 0; t < POLL_COUNT; t++) {
-		if (!(inl(ES_REG(ensoniq, 1371_CODEC)) & ES_1371_CODEC_WIP)) {
-			/* save the current state for latter */
-			x = snd_es1371_wait_src_ready(ensoniq);
-			outl((x & (ES_1371_SRC_DISABLE | ES_1371_DIS_P1 |
-			           ES_1371_DIS_P2 | ES_1371_DIS_R1)) | 0x00010000,
-			     ES_REG(ensoniq, 1371_SMPRATE));
-			/* wait for not busy (state 0) first to avoid
-			   transition states */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
-				    0x00000000)
-					break;
-			}
-			/* wait for a SAFE time to write addr/data and then do it, dammit */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
-				    0x00010000)
-					break;
-			}
-			outl(ES_1371_CODEC_WRITE(reg, val), ES_REG(ensoniq, 1371_CODEC));
-			/* restore SRC reg */
-			snd_es1371_wait_src_ready(ensoniq);
-			outl(x, ES_REG(ensoniq, 1371_SMPRATE));
-			mutex_unlock(&ensoniq->src_mutex);
-			return;
-		}
-	}
+	_es1371_codec_write(ensoniq, ES_1371_CODEC_WRITE(reg, val));
 	mutex_unlock(&ensoniq->src_mutex);
-	snd_printk(KERN_ERR "codec write timeout at 0x%lx [0x%x]\n",
-		   ES_REG(ensoniq, 1371_CODEC), inl(ES_REG(ensoniq, 1371_CODEC)));
 }
 
 static unsigned short snd_es1371_codec_read(struct snd_ac97 *ac97,
 					    unsigned short reg)
 {
 	struct ensoniq *ensoniq = ac97->private_data;
-	unsigned int t, x, fail = 0;
+	unsigned int fail;
+	unsigned long end_time;
 
-      __again:
 	mutex_lock(&ensoniq->src_mutex);
-	for (t = 0; t < POLL_COUNT; t++) {
-		if (!(inl(ES_REG(ensoniq, 1371_CODEC)) & ES_1371_CODEC_WIP)) {
-			/* save the current state for latter */
-			x = snd_es1371_wait_src_ready(ensoniq);
-			outl((x & (ES_1371_SRC_DISABLE | ES_1371_DIS_P1 |
-			           ES_1371_DIS_P2 | ES_1371_DIS_R1)) | 0x00010000,
-			     ES_REG(ensoniq, 1371_SMPRATE));
-			/* wait for not busy (state 0) first to avoid
-			   transition states */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
-				    0x00000000)
-					break;
+	for (fail = 0; fail < 10; fail++) {
+		_es1371_codec_write(ensoniq, ES_1371_CODEC_READS(reg));
+		/* wait for WIP again */
+		_es1371_wait_wip(ensoniq);
+		/* now wait for the stinkin' data (RDY) */
+		end_time = jiffies + msecs_to_jiffies(100);
+		do {
+			unsigned int x = inl(ES_REG(ensoniq, 1371_CODEC));
+			if (x & ES_1371_CODEC_RDY) {
+				mutex_unlock(&ensoniq->src_mutex);
+				return ES_1371_CODEC_READ(x);
 			}
-			/* wait for a SAFE time to write addr/data and then do it, dammit */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if ((inl(ES_REG(ensoniq, 1371_SMPRATE)) & 0x00870000) ==
-				    0x00010000)
-					break;
-			}
-			outl(ES_1371_CODEC_READS(reg), ES_REG(ensoniq, 1371_CODEC));
-			/* restore SRC reg */
-			snd_es1371_wait_src_ready(ensoniq);
-			outl(x, ES_REG(ensoniq, 1371_SMPRATE));
-			/* wait for WIP again */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if (!(inl(ES_REG(ensoniq, 1371_CODEC)) & ES_1371_CODEC_WIP))
-					break;		
-			}
-			/* now wait for the stinkin' data (RDY) */
-			for (t = 0; t < POLL_COUNT; t++) {
-				if ((x = inl(ES_REG(ensoniq, 1371_CODEC))) & ES_1371_CODEC_RDY) {
-					mutex_unlock(&ensoniq->src_mutex);
-					return ES_1371_CODEC_READ(x);
-				}
-			}
-			mutex_unlock(&ensoniq->src_mutex);
-			if (++fail > 10) {
-				snd_printk(KERN_ERR "codec read timeout (final) "
-					   "at 0x%lx, reg = 0x%x [0x%x]\n",
-					   ES_REG(ensoniq, 1371_CODEC), reg,
-					   inl(ES_REG(ensoniq, 1371_CODEC)));
-				return 0;
-			}
-			goto __again;
-		}
+		} while (time_after_eq(end_time, jiffies));
 	}
+	snd_printk(KERN_ERR "codec read timeout (final) "
+		   "at 0x%lx, reg = 0x%x [0x%x]\n",
+		   ES_REG(ensoniq, 1371_CODEC), reg,
+		   inl(ES_REG(ensoniq, 1371_CODEC)));
 	mutex_unlock(&ensoniq->src_mutex);
-	snd_printk(KERN_ERR "es1371: codec read timeout at 0x%lx [0x%x]\n",
-		   ES_REG(ensoniq, 1371_CODEC), inl(ES_REG(ensoniq, 1371_CODEC)));
 	return 0;
 }
 

[-- 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: is this card supported by ALSA?

[Landis McGauhey]

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




> Date: Tue, 15 Jul 2008 16:19:40 +0200
> From: tiwai@suse.de
> To: rene.herman@keyaccess.nl
> CC: b3zdomny@hotmail.com; alsa-user@lists.sourceforge.net; alsa-devel@alsa-project.org
> Subject: Re: [Alsa-user] is this card supported by ALSA?
> 
> At Tue, 15 Jul 2008 15:11:09 +0200,
> I wrote:
> > 
> > At Tue, 15 Jul 2008 02:11:41 +0200,
> > Rene Herman wrote:
> > > 
> > > On 15-07-08 01:36, Landis McGauhey wrote:
> > > 
> > > It seems there's just a bit too much oddness going on. Takashi, you know 
> > > more about ac97. Also bringing in alsa-devel...
> > > 
> > > > # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0=
> > > > 
> > > > 0-0/0: 0x76058384 F�S
> > > 
> > > Eep? A 0x83847605 would be a SigmaTel STAC9704. And:
> > > 
> > > [ ... ]
> > > 
> > > > # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0+regs=
> > > 
> > > [ ... ]
> > > 
> > > > 0:7c = 0000
> > > > 0:7e = 8384
> > > 
> > > does't fit the above ID. Do we just have a crummy codec that needs delay 
> > > between acceses somewhere or something?
> > 
> > I guess it's rather the controller code.  Will check this later.
> 
> The below is a patch to improve the codec access routines in a bit
> more robust way (and clean-ups, too).  Give it a try.
> 
> 
> Takashi
> 
> ---
<snip>

Thank you very much, Takashi!  I'll bet this is the solution, and I'll get right on it.

Best regards from Northern California USA,

Landis

_________________________________________________________________
Use video conversation to talk face-to-face with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_072008

[-- Attachment #1.2: Type: text/html, Size: 2292 bytes --]

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: is this card supported by ALSA?

[Landis McGauhey]

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




> Date: Tue, 15 Jul 2008 16:42:05 +0200
> From: rene.herman@keyaccess.nl
> To: b3zdomny@hotmail.com
> CC: tiwai@suse.de; alsa-user@lists.sourceforge.net; alsa-devel@alsa-project.org
> Subject: Re: [Alsa-user] is this card supported by ALSA?
> 
<snip>

Thank you, Rene, for reading my mind.  I was wondering how to go about using the patch.  As stated in my earlier message, I'm getting right on it now (second cup of morning coffee in hand!), and I'll let you know the result as soon as possible.  I really appreciate this help-- this is the type of community that makes me a Linux user-- never would any help like this be available in the WinTel world.

Best regards from Northern California USA,

Landis

_________________________________________________________________
Making the world a better place one message at a time.
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_BetterPlace

[-- Attachment #1.2: Type: text/html, Size: 1172 bytes --]

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: is this card supported by ALSA?

[Rene Herman]

On 15-07-08 16:52, Landis McGauhey wrote:

> the result as soon as possible.  I really appreciate this help-- this is 
> the type of community that makes me a Linux user-- never would any help 
> like this be available in the WinTel world.

Nor would the bug though... ;-/

Rene.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: is this card supported by ALSA?

[Sergei Steshenko]

-----Original Message-----
From: Rene Herman <rene.herman@keyaccess.nl>
To: Landis McGauhey <b3zdomny@hotmail.com>
Date: Tue, 15 Jul 2008 16:59:45 +0200
Subject: Re: [Alsa-user] is this card supported by ALSA?


> 
> Nor would the bug though... ;-/
> 
> Rene.

And that's why something equivalent to 'ndiswrapper' for audio is necessary.

Regards,
  Sergei.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: [Alsa-user] is this card supported by ALSA?

[Rene Herman]

On 15-07-08 17:01, Sergei Steshenko wrote:

> And that's why something equivalent to 'ndiswrapper' for audio is 
> necessary.

Please note -- if you're _trying_ to be a troll, it's too obvious to 
have the fun last longer than this message.

Rene.

Re: is this card supported by ALSA?

[Landis McGauhey]

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




> Date: Tue, 15 Jul 2008 16:42:05 +0200
> From: rene.herman@keyaccess.nl
> To: b3zdomny@hotmail.com
> CC: tiwai@suse.de; alsa-user@lists.sourceforge.net; alsa-devel@alsa-project.org
> Subject: Re: [Alsa-user] is this card supported by ALSA?
<snip>

OK, interim report:

the patch, the make, the makemodules, and the modprobes all proceeded without error.

ran alsamixer and verified all functions were unmuted and raised

then, the audio-test attempts:

# aplay /usr/share/sounds/startup3.wav
ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave
aplay: main:564: audio open error: No such file or directory

# speaker-test

speaker-test 1.0.16

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave
Playback open error: -2,No such file or directory


So now I'm going to run alsaconf and see if that changes things.  I'll let you know what happens.

Landis

_________________________________________________________________
Use video conversation to talk face-to-face with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_072008

[-- Attachment #1.2: Type: text/html, Size: 1546 bytes --]

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] is this card supported by ALSA?

[Rene Herman]

On 15-07-08 17:25, Landis McGauhey wrote:
> 
> 
>  > Date: Tue, 15 Jul 2008 16:42:05 +0200
>  > From: rene.herman@keyaccess.nl
>  > To: b3zdomny@hotmail.com
>  > CC: tiwai@suse.de; alsa-user@lists.sourceforge.net; 
> alsa-devel@alsa-project.org
>  > Subject: Re: [Alsa-user] is this card supported by ALSA?
> <snip>
> 
> OK, interim report:
> 
> the patch, the make, the makemodules, and the modprobes all proceeded 
> without error.

the "make modules_install" I hope. "make modules" would just make the 
modules, not install them. You need to be very sure you're running the 
new;y compiled driver (ie, as said, unload any current driver, and 
reload after the make modules_install).

Whatever the result, sound or no, please also report the 
/proc/asound/AudioPCI/code97#0/ files

> # aplay /usr/share/sounds/startup3.wav
> ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave
> aplay: main:564: audio open error: No such file or directory

Quite frankly, I haven't a clue what _that_ is now about again all of a 
sudden, but also try "aplay -D hw:AudioPCI foo.wav".

Rene.

Re: is this card supported by ALSA?

[Landis McGauhey]

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




> Date: Tue, 15 Jul 2008 16:42:05 +0200
> From: rene.herman@keyaccess.nl
> To: b3zdomny@hotmail.com
> CC: tiwai@suse.de; alsa-user@lists.sourceforge.net; alsa-devel@alsa-project.org
> Subject: Re: [Alsa-user] is this card supported by ALSA?
> 
<snip>

OK, ran alsaconf and it detected the card and finished without error.  Plus, when it loaded the driver, there was a loud "click" in the speakers.  I don't think that has happened before.

Then, the audio tests:

# speaker-test

speaker-test 1.0.16

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 2048 to 16384
Period size range from 1024 to 1024
Using max buffer size 16384
Periods = 4
was set period_size = 1024
was set buffer_size = 16384
 0 - Front Left
Time per period = 2.664700
 0 - Front Left

but with silence.

# aplay /usr/share/sounds/startup3.wav
Playing WAVE '/usr/share/sounds/startup3.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
aplay: set_params:1017: unable to install sw params:
start_mode: DATA
xrun_mode: STOP
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 940
xfer_align: 940
silence_threshold: 0
silence_size: 0
boundary: 986447872

but with silence.

tried running audacity.  according to kde system guard process table, audacity was running, but it did not appear on the screen.   Used kde system guard process table to kill audacity.

ran xmms.  song played without error, but with silence.

Now I am going to do the blacklisting you suggested and reboot to see if that makes any difference.  I will let you know what happens.

Landis 

_________________________________________________________________
The i’m Talkaton. Can 30-days of conversation change the world?
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_ChangeWorld

[-- Attachment #1.2: Type: text/html, Size: 2277 bytes --]

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: is this card supported by ALSA?

[Landis McGauhey]

> Date: Tue, 15 Jul 2008 17:36:14 +0200
> From: rene.herman@keyaccess.nl
> To: b3zdomny@hotmail.com
> CC: tiwai@suse.de; alsa-user@lists.sourceforge.net; alsa-devel@alsa-project.org
> Subject: Re: [Alsa-user] is this card supported by ALSA?
>
> On 15-07-08 17:25, Landis McGauhey wrote:
>>
>>
>>> Date: Tue, 15 Jul 2008 16:42:05 +0200
>>> From: rene.herman@keyaccess.nl
>>> To: b3zdomny@hotmail.com
>>> CC: tiwai@suse.de; alsa-user@lists.sourceforge.net;
>> alsa-devel@alsa-project.org
>>> Subject: Re: [Alsa-user] is this card supported by ALSA?
>> 
>>
>> OK, interim report:
>>
>> the patch, the make, the makemodules, and the modprobes all proceeded
>> without error.
>
> the "make modules_install" I hope. "make modules" would just make the
> modules, not install them. You need to be very sure you're running the
> new;y compiled driver (ie, as said, unload any current driver, and
> reload after the make modules_install).
>
> Whatever the result, sound or no, please also report the
> /proc/asound/AudioPCI/code97#0/ files
>
>> # aplay /usr/share/sounds/startup3.wav
>> ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave
>> aplay: main:564: audio open error: No such file or directory
>
> Quite frankly, I haven't a clue what _that_ is now about again all of a
> sudden, but also try "aplay -D hw:AudioPCI foo.wav".
>
> Rene.

OK, double-checked command line and make modules_install indeed had been run.

Went kmenu>settings>sound & multimedia>sound system>hardware tab and restarted the sound system.

Went to process table and killed many, many sessions of artsd-- seems I've read elsewhere here on the board that any sound server will block any other application trying to play.

# aplay /usr/share/sounds/startup3.wav
Playing WAVE '/usr/share/sounds/startup3.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
aplay: set_params:1017: unable to install sw params:
start_mode: DATA
xrun_mode: STOP
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 940
xfer_align: 940
silence_threshold: 0
silence_size: 0
boundary: 986447872

tried to run audacity but as before it would not appear on the screen.  used process table to kill it. 

ran xmms:  played song but with silence.

# cat /proc/asound/AudioPCI/codec97#0/ac97#0-0=
0-0/0: 0x76058384 F�S

PCI Subsys Vendor: 0x0000
PCI Subsys Device: 0x0000

Capabilities     : -dedicated MIC PCM IN channel- -bass & treble-
DAC resolution   : 16-bit
ADC resolution   : 20-bit
3D enhancement   : Reserved 29

Current setup
Mic gain         : +0dB [+20dB]
POP path         : pre 3D
Sim. stereo      : off
3D enhancement   : off
Loudness         : off
Mono output      : MIX
Mic select       : Mic1
ADC/DAC loopback : off

# cat /proc/asound/AudioPCI/codec97#0/ac97#0-0+regs=
0:00 = 0000
0:02 = 8404
0:04 = 8404
0:06 = 8000
0:08 = 8005
0:0a = ffff
0:0c = 100a
0:0e = 801f
0:10 = 805f
0:12 = 9010
0:14 = 8707
0:16 = 9f1f
0:18 = 9f1f
0:1a = 8a0a
0:1c = 8000
0:1e = 0000
0:20 = 0000
0:22 = 0000
0:24 = 0000
0:26 = 0000
0:28 = 000f
0:2a = ffff
0:2c = ffff
0:2e = ffff
0:30 = ffff
0:32 = ffff
0:34 = ffff
0:36 = ffff
0:38 = ffff
0:3a = ffff
0:3c = ffff
0:3e = ffff
0:40 = ffff
0:42 = ffff
0:44 = ffff
0:46 = ffff
0:48 = ffff
0:4a = ffff
0:4c = ffff
0:4e = ffff
0:50 = ffff
0:52 = ffff
0:54 = ffff
0:56 = ffff
0:58 = ffff
0:5a = ffff
0:5c = 0000
0:5e = 0000
0:60 = 0000
0:62 = 0000
0:64 = 0000
0:66 = 0000
0:68 = 0000
0:6a = 0000
0:6c = 0000
0:6e = 0000
0:70 = 0000
0:72 = 0000
0:74 = 0000
0:76 = 0000
0:78 = 0000
0:7a = 0000
0:7c = 0000
0:7e = 8384


Will do blacklist as recommended in earlier message, then reboot and see what happens.

Landis





_________________________________________________________________
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: is this card supported by ALSA?

[Rene Herman]

On 15-07-08 18:45, Landis McGauhey wrote:

> # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0=
> 0-0/0: 0x76058384 F�S

[ ... ]

> 0:7c = 0000
> 0:7e = 8384
> 
> 
> Will do blacklist as recommended in earlier message, then reboot and see what happens.

Nah, don't bother. If you are sure the display of the codec files above 
is with the patched driver, nothing changed, and something is still very 
wrong. I need to be gone now again but will re-stare at things again at 
earliest possible opportunity.

Rene.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] is this card supported by ALSA?

[Rene Herman]

On 15-07-08 16:42, Rene Herman wrote:

> On 15-07-08 16:19, Takashi Iwai wrote:
> 
>> The below is a patch to improve the codec access routines in a bit
>> more robust way (and clean-ups, too).  Give it a try.
> 
> Thank you for taking this...
> 
> Landis, if it's easier for you due to webmail stuff, I'm attaching the 
> patch to this message so that it might be easier for you to save it 
> (Takashi posted it "inline" in the message).
> 
> The way to use this is very similar to what you did for the OSS driver 
> patch. You save this somewhere, then from the root of the source tree 
> (from /usr/src/linux-2.6.25.9 it was...) you do
> 
> # patch -p1 --dry-run < /some/where/ens1371-ac97.diff
> 
> and upon seeing that complete without errors, without the --dry-run:
> 
> # patch -p1 --dry-run < /some/where/ens1371-ac97.diff

Just in case... I did _say_ "without the --dry-run" but then neglected 
to actually delete it from the second line here. You _did_ delete it, right?

> You then recompile the kernel with "make" (which should now only 
> recompile the snd-ens1371 driver) and do a "make modules_install" after 
> it finishes.
> 
> Then, make sure no old driver for the card is loaded:
> 
> # modprobe -r snd-ens1371
> # modprobe -r es1371
> 
> and load the new one:
> 
> # modprobe snd-ens1371
> 
> then up and unmute volumes in alsamixer again and try if you have sound 
> with "speaker-test" or "aplay foo.wav".
> 
> If you do, you should blacklist the now installed OSS es1371 driver (add 
> "blacklist es1371" to /etc/modprobe.d/blacklist) and make sure 
> snd-ens1371 is no longer blacklisted. If all's well, working sound 
> should then survive a reboot (and a future kernel would include the fix 
> autonmatically so things just work out of the box).

Off,
Rene.

Re: is this card supported by ALSA?

[Landis McGauhey]

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




> Date: Tue, 15 Jul 2008 18:52:42 +0200
> From: rene.herman@keyaccess.nl
> To: b3zdomny@hotmail.com
> CC: tiwai@suse.de; alsa-user@lists.sourceforge.net; alsa-devel@alsa-project.org
> Subject: Re: [Alsa-user] is this card supported by ALSA?
> 
> On 15-07-08 18:45, Landis McGauhey wrote:
> 
> > # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0=
> > 0-0/0: 0x76058384 F�S
> 
> [ ... ]
> 
> > 0:7c = 0000
> > 0:7e = 8384
> > 
> > 
> > Will do blacklist as recommended in earlier message, then reboot and see what happens.
> 
> Nah, don't bother. If you are sure the display of the codec files above 
> is with the patched driver, nothing changed, and something is still very 
> wrong. I need to be gone now again but will re-stare at things again at 
> earliest possible opportunity.
> 
> Rene.

Yes, I'm sure that's with the patched driver.  Have a good evening's rest and I'll see you again when convenient for you.  Thanks for all your help.

Landis

_________________________________________________________________
Use video conversation to talk face-to-face with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_072008

[-- Attachment #1.2: Type: text/html, Size: 1577 bytes --]

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

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

_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Re: [Alsa-user] is this card supported by ALSA?

[Takashi Iwai]

At Wed, 16 Jul 2008 11:16:32 +0200,
Rene Herman wrote:
> 
> On 15-07-08 22:28, Landis McGauhey wrote:
> 
> > Yes, I did delete '-dry-run'.
> > 
> > In fact, just to be doubly certain, I just re-ran the whole process and
> 
> I still worry a little bit, since if all's well, you should have seen 
> the "patch -p1" command fail this time (it commenting that the patch 
> seemed already applied) but I'll assume you did see that then. It's 
> unfortunate that the problem with your card seems involved in a way 
> which makes it fairly hard to debug this while not having the card 
> locally to fiddle around with, adding delays between things ...
> 
> > additionally ran alsaconf (and again there was a loud 'click' in the 
> > speakers when alsaconf loaded the driver):
> > 
> > # cat /proc/asound/AudioPCI/codec97#0/ac97#0-0=
> > 0-0/0: 0x83848384 STS
> 
> ... because, lovely, yet another variant.

Well, from The fact that this is repeated numbers, I guess this is a
result of (still) wrong codec communication.  Likely the previous
number remains to the next read.

I guess my patch did something wrong, too -- at least, waiting for SRC
up/down shouldn't be with sleep but a busy loop.

> There is an interface problem 
> between the ES1371 and (supposed) STAC9704 chips on your card and even 
> though that MIGHT not be all the problem (even though the ALSA driver 
> doesn't recognize your AC97 codec due to this, the OSS driver also 
> drives it without any special quirks) this will need to be taken care of 
> first.
> 
> With the card locally, the attached is the first thing I'd try. It makes 
> the driver wait around a bit to have the codec recover from reset. Apply 
> it as before, run "make" and "make modules_install" and re-load the 
> snd-ens1371 driver with (as root) "modprobe -r snd-ens1371 && modprobe 
> -r es1371 && modprobe snd-ens1371" after which ALSA sound may or may not 
> work (test through aplay).
> 
> (note by the way that for now I'm foregoing any other problems you have 
> with rebooting not loading the correct driver and such -- your dmesg 
> indicated that the OSS es1371 driver was loading even though you said 
> you blacklisted that, so just do the manual modprobe/modprobe -r stuff.)
> 
> Please also make sure that, after loading the newly patched snd-ens1371, 
> there's nothing interesting at the end of dmesg -- nothing about 
> timeouts and such. If there is something, please post.

Yeah, the kernel messages are really important.  Some messages should
appear if the codec access timeout occured.  Then it can explains why
zero is read for many registers.


Takashi

Re: [Alsa-user] is this card supported by ALSA?

[Rene Herman]

On 16-07-08 15:38, Landis McGauhey wrote:

> "pop" in speaker as alsaconf loads snd-ens1371
> 
> running alsamixer-- no mute toggle underneath mic, that's a first
> 
> and just so you know,  there's no mute toggle under "master", 
> "master-m", and "PCM", either, but that's nominal.  There was one
> time, however, that "master" and/or "PCM" had a mute toggle.  Perhaps
> "master" and/or "PCM" are muted and we can't tell because there are
> supposed to be mute toggles there, but they are missing?  Something
> to consider...

I'm afraid that codec communication is just really messed up and the 
last two patches seem to have made things worse, so in preparation for 
any possible follow ups, you might as well revert those:

from /usr/src/linux-2.6.25.9:

# moodprobe -r  ens1371-ac97_reset_hack.diff
# moodprobe -r  ens1371-ac97.diff

do please again run "make" and "make modules_install" after this but 
that's just so that I'm satisfied you're back at the start. No need to 
test anything, you'd just find the old behaviour again.

One thing I am noticing now that we've been looking at the codec ID in 
ALSA in the OSS driver output there:

===
es1371: found chip, vendor id 0x1102 device id 0x8938 revision 0x00
es1371: found es1371 rev 0 at io 0xde80 irq 23
es1371: Enabling internal amplifier.
ac97_codec: AC97 Audio codec, id:  (Unknown)
gameport: ESS1371 Gameport is isa0218/gameport0, io 0x218, speed 1125kHz
===

is the "id: (Unknown)" bit. The OSS driver also definitely knows about 
the Sigmatel STAC9704 codec so it seems _this_ problam might not be 
unique to the ALSA driver. The OSS driver does produce sound, so perhaps 
we're chasing something not maximally productive right now...

It would be sort of interesting to have you look at the physical card 
and verify that it's indeed a Sigmatel STAC9704. It should be a tiny 
chip with a greek sigma sign and "STAC9704" in small enough letters that 
you might even need a magnifying glass. If it's hard or clumsy to take 
it out, don't bother though, it's not that important. You had 76058384 
as an ID and a STAC9704 is 83847605 (upper/lower 16-bit switched) but 
that will not have gotten to be there by accident.

Yes, before anyone wonders, I verified that the ALSA driver does that 
"Enabling internal amplifier" thing (that might be that pop that you 
hear; is the pop also present when loading the OSS driver?)

> Rene & Takashi: I fear this is taking up too much of our time and
> this effort may have long passed the point of diminishing returns. 
> Personally, my goal is to have audio with Skype, whether with OSS or
> ALSA, I don't care.  If you want to continue to work on this for the
> sake of the community at large and others who have this same card
> and this same problem, then I'm willing and would be honored to be
> the guinea pig and be an active participant in the community. I'm
> sorry this problem is so stubborn and if you have better things to
> do, I understand.  If you don't care to work on this anymore, I would
> understand and if you could perhaps just help me get sound in Skype
> (that is, to have /dev/dsp appear as I/O options in Skype
> configuration) with OSS, then I would be a happy camper indeed.

I'm afraid I don't know Skype. Older versions of it couldn't use ALSA 
but needed the OSS emulation. If newer version now can't use OSS but 
need ALSA, lovely...

I'll keep looking for a bit but ofcourse you don't have to wait around 
for anything. If I find anything with a good chance of success I'll let 
you know. Please conform that you've reverted the last two patches as 
mentioned above.

Rene.

Re: [Alsa-user] is this card supported by ALSA?

[Rene Herman]

On 16-07-08 16:40, Rene Herman wrote:

> # moodprobe -r  ens1371-ac97_reset_hack.diff
> # moodprobe -r  ens1371-ac97.diff

I'm getting really sick of the fact that I seem to need to make at least 
one typo or other small error per post. "modprobe" ofcourse.

Rene.

Re: [Alsa-user] is this card supported by ALSA?

[Rene Herman]

On 16-07-08 16:44, Rene Herman wrote:

> On 16-07-08 16:40, Rene Herman wrote:
> 
>> # moodprobe -r  ens1371-ac97_reset_hack.diff
>> # moodprobe -r  ens1371-ac97.diff
> 
> I'm getting really sick of the fact that I seem to need to make at least 
> one typo or other small error per post. "modprobe" ofcourse.

Oh, I so love myself. Try this instead:

# patch -p1 -r < ens1371-ac97_reset_hack.diff
# patch -p1 -r < ens1371-ac97.diff

I'll make sure I get some sleep before I post again.

Rene.

Re: [Alsa-user] is this card supported by ALSA?

[Landis McGauhey]

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




> Date: Wed, 16 Jul 2008 16:52:39 +0200
> From: rene.herman@keyaccess.nl
> To: b3zdomny@hotmail.com
> CC: tiwai@suse.de; alsa-user@lists.sourceforge.net; alsa-devel@alsa-project.org; ALSA@sc8-sf-spam2.sourceforge.net
> Subject: Re: [Alsa-user] is this card supported by ALSA?
> 
> On 16-07-08 16:44, Rene Herman wrote:
> 
> > On 16-07-08 16:40, Rene Herman wrote:
> > 
> >> # moodprobe -r  ens1371-ac97_reset_hack.diff
> >> # moodprobe -r  ens1371-ac97.diff
> > 
> > I'm getting really sick of the fact that I seem to need to make at least 
> > one typo or other small error per post. 'modprobe' ofcourse.
> 
> Oh, I so love myself. Try this instead:
> 
> # patch -p1 -r < ens1371-ac97_reset_hack.diff
> # patch -p1 -r < ens1371-ac97.diff
> 
> I'll make sure I get some sleep before I post again.
> 
> Rene.


OK, this is interesting:

 # patch -p1 -r < ens1371-ac97_reset_hack.diff=
bash: ens1371-ac97_reset_hack.diff: No such file or directory

# patch -p1 -r < ens1371-ac97.diff
bash: ens1371-ac97.diff: No such file or directory

Go figure.

Attached are two high-res pix of the card.  The smallest chips were just too darned small for me to read the printing; maybe you can magnify the pix and make something of them.  Thanks again for all your help.  I think I'm just going to be happy with OSS for awhile and see if I can't get it to support Skype.  If you decide to keep working on this and you want to test something, you're welcome to contact me.

best regards as always,

Landis
 
_________________________________________________________________
Keep your kids safer online with Windows Live Family Safety.
http://www.windowslive.com/family_safety/overview.html?ocid=TXT_TAGLM_WL_family_safety_072008

[-- Attachment #2: p7163034.jpg --]
[-- Type: image/jpeg, Size: 2448672 bytes --]

[-- Attachment #3: p7163032.jpg --]
[-- Type: image/jpeg, Size: 2183175 bytes --]

[-- Attachment #4: 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: [Alsa-user] is this card supported by ALSA?

[Rene Herman]

On 16-07-08 20:00, Landis McGauhey wrote:

> OK, this is interesting:
> 
> # patch -p1 -r < ens1371-ac97_reset_hack.diff=
> bash:ens1371-ac97_reset_hack.diff: No such file or directory
> 
> # patch -p1 -r < ens1371-ac97.diff
> bash: ens1371-ac97.diff: No such file or directory
> 
> Go figure.

Of course. You've done this a number of times now, so I took for granted 
that by now you'd understand to put in the path yourself. You saved 
these diff's from earlier mssages.

> Attached are two high-res pix of the card. The smallest chips were
> just too darned small for me to read the printing; maybe you can
> magnify the pix and make something of them.

A CT4730. You have an onboard amp (and it's disabled -- setting both the 
jumpers to the SPK position enables it but keeping it disabled is better 
if you don't really need it; these opamps suck).

Moreover, the AC97 codec seems integrated in the EV1938. Just found a 
patch for FreeBSD following up a similar report for your card. Will look 
at it tomorrow.

Rene.

Re: [Alsa-user] is this card supported by ALSA?

[Rene Herman]

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

On 16-07-08 20:50, Rene Herman wrote:

> Moreover, the AC97 codec seems integrated in the EV1938. Just found a
> patch for FreeBSD following up a similar report for your card. Will
> look at it tomorrow.

Nothing interesting. Ready to give up on this. There is a communication 
problem with the AC97 codec and that's the kind of thing which is almost 
impossible to debug via email, especially since apparently this is not 
different for the OSS driver; it's also not getting back a valid ID at 
least.

I do wonder a bit if that might mean that the only difference is the 
ALSA "mute by default" behaviour. The attached patch does away with the 
default muting of the AC97 controls. You'd apply it as before (after 
reverting the previous 2 patches as written earlier), "make", "make 
modules_install" and then load snd-ens1371:

# modprobe -r es1371
# modprobe -r snd-ens1371
# modprobe snd-ens1371

and then "aplay foo.wav" (without first starting alsamixer). If no 
sound, adjust levels in alsamixer, retry aplay, if no sound, reboot (to 
get the card to a startup state) and retry after the above 3 modprobes.

If for some unimagineable reason you still need "alsaconf" instead of 
just modprobe snd-ens1371 to load the driver, adjust accordingly. Have 
no idea why that would be the case.

If as expected you still have no sound I give up. Stared at this stuff, 
but am not seeing anything stand out. If you ever decide to replace the 
card and can find an ALSA developer in your neighbourhood to donate it 
to that could be interesting. I've never seen an EV1938 locally here; 
distribution is probably limited to the US.

Rene.

[-- Attachment #2: ac97_dont_mute.diff --]
[-- Type: text/plain, Size: 428 bytes --]

diff --git a/sound/pci/ac97/ac97_codec.c b/sound/pci/ac97/ac97_codec.c
index 4f4343d..97a4365 100644
--- a/sound/pci/ac97/ac97_codec.c
+++ b/sound/pci/ac97/ac97_codec.c
@@ -1196,8 +1196,6 @@ static int snd_ac97_cmute_new_stereo(struct snd_card *card, char *name, int reg,
 	err = snd_ctl_add(card, kctl);
 	if (err < 0)
 		return err;
-	/* mute as default */
-	snd_ac97_write_cache(ac97, reg, val | mute_mask);
 	return 0;
 }
 

[-- 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