Re: [alsa-devel] [Alsa-user] is this card supported by ALSA?
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.
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
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
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...
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; }
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.
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; }
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
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.
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...
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.
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...
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.
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...
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
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.
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...
participants (3)
-
Landis McGauhey -
Rene Herman -
Takashi Iwai