another device for opl3sa2

another device for opl3sa2

[Paul Vojta]

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

Re: another device for opl3sa2

[Takashi Iwai]

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

Re: another device for opl3sa2

[Paul Vojta]

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

Re: another device for opl3sa2

[Takashi Iwai]

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

Re: another device for opl3sa2

[Paul Vojta]

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

Re: another device for opl3sa2

[Takashi Iwai]

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

Re: another device for opl3sa2

[Paul Vojta]

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

Re: another device for opl3sa2

[Takashi Iwai]

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:
> 
> 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.

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

Re: another device for opl3sa2

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

Re: another device for opl3sa2

[Takashi Iwai]

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

Re: another device for opl3sa2

[Paul Vojta]

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

Re: another device for opl3sa2

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

Re: another device for opl3sa2

[Takashi Iwai]

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