[alsa-devel] another device for opl3sa2
Folks:
Here's a patch to add support for an (admittedly old) device:
--- linux-2.6.21.5/sound/isa/opl3sa2.c.orig 2007-06-11 11:37:06.000000000 -0700 +++ linux-2.6.21.5/sound/isa/opl3sa2.c 2007-06-30 23:29:43.000000000 -0700 @@ -165,6 +165,8 @@ { .id = "YMH0801", .devs = { { "YMH0021" } } }, /* NeoMagic MagicWave 3DX */ { .id = "NMX2200", .devs = { { "YMH2210" } } }, + /* NeoMagic MagicWave 3D */ + { .id = "NMX2200", .devs = { { "NMX2210" } } }, /* --- */ { .id = "" } /* end */ };
(There may be a bug in the initialization code, though -- it doesn't work the first time after booting, just the second and subsequent times. For example, the first time I try running "aplay file.wav" it'll sit there silently instead of playing the file, but if I type "aplay file.wav" again then it'll play.)
I don't know whether snd_opl3sa2_pnpbiosids[] should also be changed.
Also, why does nm256.c direct users to the cs423x drivers and not opl3sa2? If it had mentioned opl3sa2 it would have saved me many hours.
Sincerely,
Paul Vojta vojta@math.berkeley.edu
At Mon, 2 Jul 2007 17:27:39 -0700, Paul Vojta wrote:
Folks:
Here's a patch to add support for an (admittedly old) device:
--- linux-2.6.21.5/sound/isa/opl3sa2.c.orig 2007-06-11 11:37:06.000000000 -0700 +++ linux-2.6.21.5/sound/isa/opl3sa2.c 2007-06-30 23:29:43.000000000 -0700 @@ -165,6 +165,8 @@ { .id = "YMH0801", .devs = { { "YMH0021" } } }, /* NeoMagic MagicWave 3DX */ { .id = "NMX2200", .devs = { { "YMH2210" } } },
- /* NeoMagic MagicWave 3D */
- { .id = "NMX2200", .devs = { { "NMX2210" } } }, /* --- */ { .id = "" } /* end */
};
Thanks, could you give your sign-off?
(There may be a bug in the initialization code, though -- it doesn't work the first time after booting, just the second and subsequent times. For example, the first time I try running "aplay file.wav" it'll sit there silently instead of playing the file, but if I type "aplay file.wav" again then it'll play.)
What do you mean "doesn't work"? The module wasn't loaded or malfunctional?
I don't know whether snd_opl3sa2_pnpbiosids[] should also be changed.
The table you changed is for ISA-PnP, while *_pnpbiosids[] is for PnP BIOS. There are slight differences. And, "NMX2210" is already there.
Also, why does nm256.c direct users to the cs423x drivers and not opl3sa2? If it had mentioned opl3sa2 it would have saved me many hours.
Patch please? Also, it'd be better to fix ALSA-Configuration.txt, too...
Takashi
On Tue, Jul 03, 2007 at 12:05:50PM +0200, Takashi Iwai wrote:
At Mon, 2 Jul 2007 17:27:39 -0700, Paul Vojta wrote:
Folks:
Here's a patch to add support for an (admittedly old) device:
--- linux-2.6.21.5/sound/isa/opl3sa2.c.orig 2007-06-11 11:37:06.000000000 -0700 +++ linux-2.6.21.5/sound/isa/opl3sa2.c 2007-06-30 23:29:43.000000000 -0700 @@ -165,6 +165,8 @@ { .id = "YMH0801", .devs = { { "YMH0021" } } }, /* NeoMagic MagicWave 3DX */ { .id = "NMX2200", .devs = { { "YMH2210" } } },
- /* NeoMagic MagicWave 3D */
- { .id = "NMX2200", .devs = { { "NMX2210" } } }, /* --- */ { .id = "" } /* end */
};
Thanks, could you give your sign-off?
Description:
Add Neomagic MagicWave 3D to list of supported devices for opl3sa2 driver.
Signed-off by: Paul Vojta <vojta at math.berkeley.edu>
(There may be a bug in the initialization code, though -- it doesn't work the first time after booting, just the second and subsequent times. For example, the first time I try running "aplay file.wav" it'll sit there silently instead of playing the file, but if I type "aplay file.wav" again then it'll play.)
What do you mean "doesn't work"? The module wasn't loaded or malfunctional?
The driver was malfunctional the first time after reboot or rmmod+modprobe.
aplay would give all appearances of working, and waited the proper amount of time, but did not produce sound. It was as if the sound was played at volume zero.
Second and subsequent invocations of aplay worked properly.
I don't know whether snd_opl3sa2_pnpbiosids[] should also be changed.
The table you changed is for ISA-PnP, while *_pnpbiosids[] is for PnP BIOS. There are slight differences. And, "NMX2210" is already there.
Oops, sorry.
Also, why does nm256.c direct users to the cs423x drivers and not opl3sa2? If it had mentioned opl3sa2 it would have saved me many hours.
Patch please? Also, it'd be better to fix ALSA-Configuration.txt, too...
ALSA-Configuration.txt already mentions opl3sa2.
For nm256.c:
Description:
Adds mention of opl3sa2 driver to a diagnostic message for NeoMagic nm256 driver.
Signed-off by: Paul Vojta <vojta at math.berkeley.edu>
--- a/sound/pci/nm256/nm256.c 2007-06-11 11:37:06.000000000 -0700 +++ b/sound/pci/nm256/nm256.c 2007-07-03 13:00:11.000000000 -0700 @@ -1533,7 +1533,8 @@ printk(KERN_ERR " force the driver to load by " "passing in the module parameter\n"); printk(KERN_ERR " force_ac97=1\n"); - printk(KERN_ERR " or try sb16 or cs423x drivers instead.\n"); + printk(KERN_ERR " or try sb16, opl3sa2, or " + "cs423x drivers instead.\n"); err = -ENXIO; goto __error; }
Sincerely,
Paul Vojta vojta@math.berkeley.edu
At Tue, 3 Jul 2007 19:24:23 -0700, Paul Vojta wrote:
On Tue, Jul 03, 2007 at 12:05:50PM +0200, Takashi Iwai wrote:
At Mon, 2 Jul 2007 17:27:39 -0700, Paul Vojta wrote:
Folks:
Here's a patch to add support for an (admittedly old) device:
--- linux-2.6.21.5/sound/isa/opl3sa2.c.orig 2007-06-11 11:37:06.000000000 -0700 +++ linux-2.6.21.5/sound/isa/opl3sa2.c 2007-06-30 23:29:43.000000000 -0700 @@ -165,6 +165,8 @@ { .id = "YMH0801", .devs = { { "YMH0021" } } }, /* NeoMagic MagicWave 3DX */ { .id = "NMX2200", .devs = { { "YMH2210" } } },
- /* NeoMagic MagicWave 3D */
- { .id = "NMX2200", .devs = { { "NMX2210" } } }, /* --- */ { .id = "" } /* end */
};
Thanks, could you give your sign-off?
Description:
Add Neomagic MagicWave 3D to list of supported devices for opl3sa2 driver.
Signed-off by: Paul Vojta <vojta at math.berkeley.edu>
(There may be a bug in the initialization code, though -- it doesn't work the first time after booting, just the second and subsequent times. For example, the first time I try running "aplay file.wav" it'll sit there silently instead of playing the file, but if I type "aplay file.wav" again then it'll play.)
What do you mean "doesn't work"? The module wasn't loaded or malfunctional?
The driver was malfunctional the first time after reboot or rmmod+modprobe.
aplay would give all appearances of working, and waited the proper amount of time, but did not produce sound. It was as if the sound was played at volume zero.
Second and subsequent invocations of aplay worked properly.
Hm, the silence appears to be an insufficient mixer initialization. Touching mixer values doesn't help?
I don't know whether snd_opl3sa2_pnpbiosids[] should also be changed.
The table you changed is for ISA-PnP, while *_pnpbiosids[] is for PnP BIOS. There are slight differences. And, "NMX2210" is already there.
Oops, sorry.
Also, why does nm256.c direct users to the cs423x drivers and not opl3sa2? If it had mentioned opl3sa2 it would have saved me many hours.
Patch please? Also, it'd be better to fix ALSA-Configuration.txt, too...
ALSA-Configuration.txt already mentions opl3sa2.
For nm256.c:
Description:
Adds mention of opl3sa2 driver to a diagnostic message for NeoMagic nm256 driver.
Signed-off by: Paul Vojta <vojta at math.berkeley.edu>
Thanks, applied both patches now to ALSA tree.
Takashi
On Wed, Jul 04, 2007 at 10:53:05AM +0200, Takashi Iwai wrote:
At Tue, 3 Jul 2007 19:24:23 -0700,
Hm, the silence appears to be an insufficient mixer initialization. Touching mixer values doesn't help?
Not sure what you mean by "touching mixer values". I tried running alsamixer and immediately hitting Escape, but the bug still occurred.
By the way, if I use the cs-4232 driver instead, then I don't experience the problem. Of course, with cs-4232 the PNP is all wrong, so I used a non-pnp kernel with:
modprobe snd-cs4232 \ port=0x534 cport=0x120 mpu_port=0x330 fm_port=0x388 sb_port=0x220 \ irq=5 dma1=0 dma2=1
For comparison, the settings for opl3sa2 would be:
sb_port=0x220 wss_port=0x530 fm_port=0x388 midi_port=0x330 port=0x370 \ irq=5 dma1=0 dma2=1
--Paul Vojta, vojta@math.berkeley.edu
At Thu, 5 Jul 2007 01:03:02 -0700, Paul Vojta wrote:
On Wed, Jul 04, 2007 at 10:53:05AM +0200, Takashi Iwai wrote:
At Tue, 3 Jul 2007 19:24:23 -0700,
Hm, the silence appears to be an insufficient mixer initialization. Touching mixer values doesn't help?
Not sure what you mean by "touching mixer values". I tried running alsamixer and immediately hitting Escape, but the bug still occurred.
By the way, if I use the cs-4232 driver instead, then I don't experience the problem. Of course, with cs-4232 the PNP is all wrong, so I used a non-pnp kernel with:
modprobe snd-cs4232 \ port=0x534 cport=0x120 mpu_port=0x330 fm_port=0x388 sb_port=0x220 \ irq=5 dma1=0 dma2=1
For comparison, the settings for opl3sa2 would be:
sb_port=0x220 wss_port=0x530 fm_port=0x388 midi_port=0x330 port=0x370 \ irq=5 dma1=0 dma2=1
A good finding. So the possible causes are
- opl3sa specific initialization, such as snd_opl3sa2_detect() - opl3sa specific mixer element, like Master Volume.
Can your machine suspend/resume? It's interesting whether the sound is resumed well with snd-opl3sa2 driver. I remember it worked quite ago, but not tested with the recent versions.
Takashi
On Thu, Jul 05, 2007 at 04:38:57PM +0200, Takashi Iwai wrote:
A good finding. So the possible causes are
- opl3sa specific initialization, such as snd_opl3sa2_detect()
- opl3sa specific mixer element, like Master Volume.
Can your machine suspend/resume? It's interesting whether the sound is resumed well with snd-opl3sa2 driver. I remember it worked quite ago, but not tested with the recent versions.
My machine can sleep but not hibernate. After sleep the sound is resumed well.
I also edited cs4231_lib.c and changed lines 242 and 861 from "#if 0" to "#if 1" (thus enabling the call to snd_cs4231_debug(chip) at the end of snd_cs4231_playback_prepare() ). Here is the output I got:
1. module opl3sa2
a. First time running aplay:
CS4231 REGS: INDEX = 0x0e STATUS = 0xc4 0x00: left input = 0x00 0x10: alt 1 (CFIG 2) = 0x80 0x01: right input = 0x00 0x11: alt 2 (CFIG 3) = 0x01 0x02: GF1 left input = 0x06 0x12: left line in = 0x9f 0x03: GF1 right input = 0x06 0x13: right line in = 0x9f 0x04: CD left input = 0x9f 0x14: timer low = 0x00 0x05: CD right input = 0x9f 0x15: timer high = 0x00 0x06: left output = 0x0c 0x16: left MIC (PnP) = 0x80 0x07: right output = 0x0c 0x17: right MIC (PnP) = 0x80 0x08: playback format = 0x57 0x18: IRQ status = 0x00 0x09: iface (CFIG 1) = 0x08 0x19: left line out = 0x80 0x0a: pin control = 0x02 0x1a: mono control = 0x0f 0x0b: init & status = 0x20 0x1b: right line out = 0x80 0x0c: revision & mode = 0xca 0x1c: record format = 0x20 0x0d: loopback = 0xfc 0x1d: var freq (PnP) = 0x80 0x0e: ply upr count = 0x0a 0x1e: ply lwr count = 0x00 0x0f: rec upr count = 0xc3 0x1f: rec lwr count = 0x00
b. Second time running aplay:
CS4231 REGS: INDEX = 0x0e STATUS = 0xc4 0x00: left input = 0x00 0x10: alt 1 (CFIG 2) = 0x80 0x01: right input = 0x00 0x11: alt 2 (CFIG 3) = 0x01 0x02: GF1 left input = 0x06 0x12: left line in = 0x9f 0x03: GF1 right input = 0x06 0x13: right line in = 0x9f 0x04: CD left input = 0x9f 0x14: timer low = 0x00 0x05: CD right input = 0x9f 0x15: timer high = 0x00 0x06: left output = 0x0c 0x16: left MIC (PnP) = 0x80 0x07: right output = 0x0c 0x17: right MIC (PnP) = 0x80 0x08: playback format = 0x57 0x18: IRQ status = 0x00 0x09: iface (CFIG 1) = 0x08 0x19: left line out = 0x80 0x0a: pin control = 0x02 0x1a: mono control = 0x0f 0x0b: init & status = 0x00 0x1b: right line out = 0x80 0x0c: revision & mode = 0xca 0x1c: record format = 0x20 0x0d: loopback = 0xfc 0x1d: var freq (PnP) = 0x80 0x0e: ply upr count = 0x0a 0x1e: ply lwr count = 0x00 0x0f: rec upr count = 0xc3 0x1f: rec lwr count = 0x00
2. Module cs4232, both times running aplay:
CS4231 REGS: INDEX = 0x0e STATUS = 0xc4 0x00: left input = 0x00 0x10: alt 1 (CFIG 2) = 0x80 0x01: right input = 0x00 0x11: alt 2 (CFIG 3) = 0x01 0x02: GF1 left input = 0x9f 0x12: left line in = 0x9f 0x03: GF1 right input = 0x9f 0x13: right line in = 0x9f 0x04: CD left input = 0x9f 0x14: timer low = 0x00 0x05: CD right input = 0x9f 0x15: timer high = 0x00 0x06: left output = 0x0c 0x16: left MIC (PnP) = 0x80 0x07: right output = 0x0c 0x17: right MIC (PnP) = 0x80 0x08: playback format = 0x57 0x18: IRQ status = 0x00 0x09: iface (CFIG 1) = 0x08 0x19: left line out = 0x80 0x0a: pin control = 0x02 0x1a: mono control = 0xcf 0x0b: init & status = 0x00 0x1b: right line out = 0x80 0x0c: revision & mode = 0xca 0x1c: record format = 0x20 0x0d: loopback = 0xfc 0x1d: var freq (PnP) = 0x80 0x0e: ply upr count = 0x0a 0x1e: ply lwr count = 0x00 0x0f: rec upr count = 0xc3 0x1f: rec lwr count = 0x00
The value of 0x0b in the first group is different from the other two groups.
--Paul Vojta, vojta@math.berkeley.edu
At Fri, 6 Jul 2007 00:41:36 -0700, Paul Vojta wrote:
On Thu, Jul 05, 2007 at 04:38:57PM +0200, Takashi Iwai wrote:
A good finding. So the possible causes are
- opl3sa specific initialization, such as snd_opl3sa2_detect()
- opl3sa specific mixer element, like Master Volume.
Can your machine suspend/resume? It's interesting whether the sound is resumed well with snd-opl3sa2 driver. I remember it worked quite ago, but not tested with the recent versions.
My machine can sleep but not hibernate. After sleep the sound is resumed well.
I also edited cs4231_lib.c and changed lines 242 and 861 from "#if 0" to "#if 1" (thus enabling the call to snd_cs4231_debug(chip) at the end of snd_cs4231_playback_prepare() ). Here is the output I got:
- module opl3sa2
a. First time running aplay:
CS4231 REGS: INDEX = 0x0e STATUS = 0xc4 0x00: left input = 0x00 0x10: alt 1 (CFIG 2) = 0x80 0x01: right input = 0x00 0x11: alt 2 (CFIG 3) = 0x01 0x02: GF1 left input = 0x06 0x12: left line in = 0x9f 0x03: GF1 right input = 0x06 0x13: right line in = 0x9f 0x04: CD left input = 0x9f 0x14: timer low = 0x00 0x05: CD right input = 0x9f 0x15: timer high = 0x00 0x06: left output = 0x0c 0x16: left MIC (PnP) = 0x80 0x07: right output = 0x0c 0x17: right MIC (PnP) = 0x80 0x08: playback format = 0x57 0x18: IRQ status = 0x00 0x09: iface (CFIG 1) = 0x08 0x19: left line out = 0x80 0x0a: pin control = 0x02 0x1a: mono control = 0x0f 0x0b: init & status = 0x20 0x1b: right line out = 0x80 0x0c: revision & mode = 0xca 0x1c: record format = 0x20 0x0d: loopback = 0xfc 0x1d: var freq (PnP) = 0x80 0x0e: ply upr count = 0x0a 0x1e: ply lwr count = 0x00 0x0f: rec upr count = 0xc3 0x1f: rec lwr count = 0x00
b. Second time running aplay:
CS4231 REGS: INDEX = 0x0e STATUS = 0xc4 0x00: left input = 0x00 0x10: alt 1 (CFIG 2) = 0x80 0x01: right input = 0x00 0x11: alt 2 (CFIG 3) = 0x01 0x02: GF1 left input = 0x06 0x12: left line in = 0x9f 0x03: GF1 right input = 0x06 0x13: right line in = 0x9f 0x04: CD left input = 0x9f 0x14: timer low = 0x00 0x05: CD right input = 0x9f 0x15: timer high = 0x00 0x06: left output = 0x0c 0x16: left MIC (PnP) = 0x80 0x07: right output = 0x0c 0x17: right MIC (PnP) = 0x80 0x08: playback format = 0x57 0x18: IRQ status = 0x00 0x09: iface (CFIG 1) = 0x08 0x19: left line out = 0x80 0x0a: pin control = 0x02 0x1a: mono control = 0x0f 0x0b: init & status = 0x00 0x1b: right line out = 0x80 0x0c: revision & mode = 0xca 0x1c: record format = 0x20 0x0d: loopback = 0xfc 0x1d: var freq (PnP) = 0x80 0x0e: ply upr count = 0x0a 0x1e: ply lwr count = 0x00 0x0f: rec upr count = 0xc3 0x1f: rec lwr count = 0x00
- Module cs4232, both times running aplay:
CS4231 REGS: INDEX = 0x0e STATUS = 0xc4 0x00: left input = 0x00 0x10: alt 1 (CFIG 2) = 0x80 0x01: right input = 0x00 0x11: alt 2 (CFIG 3) = 0x01 0x02: GF1 left input = 0x9f 0x12: left line in = 0x9f 0x03: GF1 right input = 0x9f 0x13: right line in = 0x9f 0x04: CD left input = 0x9f 0x14: timer low = 0x00 0x05: CD right input = 0x9f 0x15: timer high = 0x00 0x06: left output = 0x0c 0x16: left MIC (PnP) = 0x80 0x07: right output = 0x0c 0x17: right MIC (PnP) = 0x80 0x08: playback format = 0x57 0x18: IRQ status = 0x00 0x09: iface (CFIG 1) = 0x08 0x19: left line out = 0x80 0x0a: pin control = 0x02 0x1a: mono control = 0xcf 0x0b: init & status = 0x00 0x1b: right line out = 0x80 0x0c: revision & mode = 0xca 0x1c: record format = 0x20 0x0d: loopback = 0xfc 0x1d: var freq (PnP) = 0x80 0x0e: ply upr count = 0x0a 0x1e: ply lwr count = 0x00 0x0f: rec upr count = 0xc3 0x1f: rec lwr count = 0x00
The value of 0x0b in the first group is different from the other two groups.
0x0b = CS4231_TEST_INIT, and 0x20 = CS4231_CALIB_IN_PROGRESS. At least, mce_down() should show messages if the calibration gets timeout. Did you see any related messages? Or didn't you build with --with-debug=full?
Takashi
On Fri, Jul 06, 2007 at 11:45:00AM +0200, Takashi Iwai wrote:
0x0b = CS4231_TEST_INIT, and 0x20 = CS4231_CALIB_IN_PROGRESS. At least, mce_down() should show messages if the calibration gets timeout. Did you see any related messages? Or didn't you build with --with-debug=full?
I didn't build with --debug=full. I've been using ALSA as supplied with linux kernel 2.6.21.1, and built without CONFIG_SND_DEBUG or CONFIG_SND_DEBUG_DETECT
I have now switched to 2.6.21.6, and turned on both of CONFIG_SND_DEBUG*. I also uncommented the printk() calls in mce_down(), and moved the first one down below the definition of the variable 'timeout'.
Here are the kernel messages I got:
Device opl3sa2:
Initialization
ALSA sound/isa/cs423x/cs4231_lib.c:1015: cs4231: port = 0x534, id = 0xa (1) timeout = 12 (1) timeout = 95 (1) timeout = 31 (1) timeout = 73 (1) timeout = 80 (1) timeout = 72 (1) timeout = 92
Ran aplay first time (no sound)
ALSA sound/isa/cs423x/cs4231_lib.c:331: mce_down [0x0] - auto calibration time out (0) (1) timeout = 72
Ran aplay second time
(1) timeout = 72
Device cs4232:
Initialization
ALSA sound/isa/cs423x/cs4231_lib.c:1015: cs4231: port = 0x534, id = 0xa ALSA sound/isa/cs423x/cs4231_lib.c:1021: CS4231: VERSION (I25) = 0x80 (1) timeout = 23 (1) timeout = 95 (1) timeout = 11 (1) timeout = 73 (1) timeout = 80 (1) timeout = 72 (2) timeout = 495, jiffies = -64562 (3) jiffies = -64558 (4) jiffies = -64558 ALSA sound/isa/cs423x/cs4231_lib.c:383: mce_down - exit = 0xb (1) timeout = 92
Ran aplay first time
ALSA sound/isa/cs423x/cs4231_lib.c:331: mce_down [0x0] - auto calibration time out (0) (1) timeout = 72 (2) timeout = 500, jiffies = -45004 (3) jiffies = -45000 (4) jiffies = -45000 ALSA sound/isa/cs423x/cs4231_lib.c:383: mce_down - exit = 0xb
Ran aplay second time
(1) timeout = 72
--Paul Vojta, vojta@math.berkeley.edu
At Sun, 8 Jul 2007 01:02:24 -0700, Paul Vojta wrote:
On Fri, Jul 06, 2007 at 11:45:00AM +0200, Takashi Iwai wrote:
0x0b = CS4231_TEST_INIT, and 0x20 = CS4231_CALIB_IN_PROGRESS. At least, mce_down() should show messages if the calibration gets timeout. Did you see any related messages? Or didn't you build with --with-debug=full?
I didn't build with --debug=full. I've been using ALSA as supplied with linux kernel 2.6.21.1, and built without CONFIG_SND_DEBUG or CONFIG_SND_DEBUG_DETECT
I have now switched to 2.6.21.6, and turned on both of CONFIG_SND_DEBUG*. I also uncommented the printk() calls in mce_down(), and moved the first one down below the definition of the variable 'timeout'.
Here are the kernel messages I got:
Device opl3sa2:
Initialization
ALSA sound/isa/cs423x/cs4231_lib.c:1015: cs4231: port = 0x534, id = 0xa (1) timeout = 12 (1) timeout = 95 (1) timeout = 31 (1) timeout = 73 (1) timeout = 80 (1) timeout = 72 (1) timeout = 92
Ran aplay first time (no sound)
ALSA sound/isa/cs423x/cs4231_lib.c:331: mce_down [0x0] - auto calibration time out (0) (1) timeout = 72
Ran aplay second time
(1) timeout = 72
Device cs4232:
Initialization
ALSA sound/isa/cs423x/cs4231_lib.c:1015: cs4231: port = 0x534, id = 0xa ALSA sound/isa/cs423x/cs4231_lib.c:1021: CS4231: VERSION (I25) = 0x80 (1) timeout = 23 (1) timeout = 95 (1) timeout = 11 (1) timeout = 73 (1) timeout = 80 (1) timeout = 72 (2) timeout = 495, jiffies = -64562 (3) jiffies = -64558 (4) jiffies = -64558 ALSA sound/isa/cs423x/cs4231_lib.c:383: mce_down - exit = 0xb (1) timeout = 92
Ran aplay first time
ALSA sound/isa/cs423x/cs4231_lib.c:331: mce_down [0x0] - auto calibration time out (0) (1) timeout = 72 (2) timeout = 500, jiffies = -45004 (3) jiffies = -45000 (4) jiffies = -45000 ALSA sound/isa/cs423x/cs4231_lib.c:383: mce_down - exit = 0xb
Ran aplay second time
(1) timeout = 72
Hmm, if I understand correctly from your debug messages, I don't see significant differences between opl3sa2 and cs4232 cases. Just to be sure, both first and second aplay on opl3sa2 didn't work (no sound output) while cs4232 was OK, right?
Takashi
On Mon, Jul 09, 2007 at 02:42:35PM +0200, Takashi Iwai wrote:
Hmm, if I understand correctly from your debug messages, I don't see significant differences between opl3sa2 and cs4232 cases.
Well, with opl3sa2, it never reaches the end of mce_down
Just to be sure, both first and second aplay on opl3sa2 didn't work (no sound output) while cs4232 was OK, right?
No, only the first aplay on opl3sa2 produced no output. The second one worked fine.
--Paul Vojta
On Fri, Jul 06, 2007 at 11:45:00AM +0200, Takashi Iwai wrote:
0x0b = CS4231_TEST_INIT, and 0x20 = CS4231_CALIB_IN_PROGRESS. At least, mce_down() should show messages if the calibration gets timeout. Did you see any related messages? Or didn't you build with --with-debug=full?
I have now recompiled the alsa drivers from alsa-driver-hg20070718 and with --debug=full.
I found that the bug would also occur the first time playing a .wav file after "aplay -t au file.au".
The difference between opl3sa2 and 4232 occurred because of the lines
if ((timeout & CS4231_MCE) == 0 || !(chip->hardware & (CS4231_HW_CS4231_MASK | CS4231_HW_CS4232_MASK))) { return; }
in mce_down() in cs4231_lib.c. With opl3sa2 it was always returning at this step, hence it didn't finish recalibrating before trying to play the sound.
If I changed it so that the second test is always false for opl3sa2, then sound would mostly work, but intermittently I would get messages about "auto calibration time out" or "serious init problem - codec still busy". If I put a printk() statement in the beginning of mce_down to help debug this, then the problem would go away, so I put in udelay(100) and that also made the problems go away.
Therefore, I submit the following patch.
Synopsis: Fix bugs in mode change/recalibration for opl3sa2 driver.
Signed-off by: Paul Vojta vojta@math.berkeley.edu
diff -ur /tmp/alsa-driver-hg20070718/alsa-kernel/include/cs4231.h alsa-driver-hg20070718/alsa-kernel/include/cs4231.h --- /tmp/alsa-driver-hg20070718/alsa-kernel/include/cs4231.h 2006-10-10 17:00:21.000000000 -0700 +++ alsa-driver-hg20070718/alsa-kernel/include/cs4231.h 2007-07-21 00:39:55.000000000 -0700 @@ -210,7 +210,7 @@ #define CS4231_HW_CS4239 0x0404 /* CS4239 - Crystal Clear (tm) stereo enhancement */ /* compatible, but clones */ #define CS4231_HW_INTERWAVE 0x1000 /* InterWave chip */ -#define CS4231_HW_OPL3SA2 0x1001 /* OPL3-SA2 chip */ +#define CS4231_HW_OPL3SA2 0x1101 /* OPL3-SA2 chip, similar to cs4231 */
/* defines for codec.hwshare */ #define CS4231_HWSHARE_IRQ (1<<0) diff -ur /tmp/alsa-driver-hg20070718/alsa-kernel/isa/cs423x/cs4231_lib.c alsa-driver-hg20070718/alsa-kernel/isa/cs423x/cs4231_lib.c --- /tmp/alsa-driver-hg20070718/alsa-kernel/isa/cs423x/cs4231_lib.c 2007-02-22 17:00:24.000000000 -0800 +++ alsa-driver-hg20070718/alsa-kernel/isa/cs423x/cs4231_lib.c 2007-07-25 22:49:04.000000000 -0700 @@ -555,6 +555,9 @@ snd_cs4231_out(chip, CS4231_PLAYBK_FORMAT, chip->image[CS4231_PLAYBK_FORMAT] = pdfr); } spin_unlock_irqrestore(&chip->reg_lock, flags); + if (chip->hardware == CS4231_HW_OPL3SA2) { + udelay(100); /* this seems to help */ + } snd_cs4231_mce_down(chip); } snd_cs4231_calibrate_mute(chip, 0); diff -ur /tmp/alsa-driver-hg20070718/alsa-kernel/isa/opl3sa2.c alsa-driver-hg20070718/alsa-kernel/isa/opl3sa2.c --- /tmp/alsa-driver-hg20070718/alsa-kernel/isa/opl3sa2.c 2007-07-04 17:00:11.000000000 -0700 +++ alsa-driver-hg20070718/alsa-kernel/isa/opl3sa2.c 2007-07-25 21:19:39.000000000 -0700 @@ -253,6 +253,7 @@ /* 0x03 - YM715B */ /* 0x04 - YM719 - OPL-SA4? */ /* 0x05 - OPL3-SA3 - Libretto 100 */ + /* 0x07 - unknown - Neomagic MagicWave 3D */ break; } str[0] = chip->version + '0';
At Fri, 27 Jul 2007 00:55:14 -0700, Paul Vojta wrote:
On Fri, Jul 06, 2007 at 11:45:00AM +0200, Takashi Iwai wrote:
0x0b = CS4231_TEST_INIT, and 0x20 = CS4231_CALIB_IN_PROGRESS. At least, mce_down() should show messages if the calibration gets timeout. Did you see any related messages? Or didn't you build with --with-debug=full?
I have now recompiled the alsa drivers from alsa-driver-hg20070718 and with --debug=full.
I found that the bug would also occur the first time playing a .wav file after "aplay -t au file.au".
The difference between opl3sa2 and 4232 occurred because of the lines
if ((timeout & CS4231_MCE) == 0 || !(chip->hardware & (CS4231_HW_CS4231_MASK | CS4231_HW_CS4232_MASK))) { return; }
in mce_down() in cs4231_lib.c. With opl3sa2 it was always returning at this step, hence it didn't finish recalibrating before trying to play the sound.
If I changed it so that the second test is always false for opl3sa2, then sound would mostly work, but intermittently I would get messages about "auto calibration time out" or "serious init problem - codec still busy". If I put a printk() statement in the beginning of mce_down to help debug this, then the problem would go away, so I put in udelay(100) and that also made the problems go away.
Therefore, I submit the following patch.
Synopsis: Fix bugs in mode change/recalibration for opl3sa2 driver.
Signed-off by: Paul Vojta vojta@math.berkeley.edu
Great, finally you spotted out. I applied it to ALSA HG tree now.
thanks,
Takashi
participants (2)
-
Paul Vojta -
Takashi Iwai