Requested: CMI8330 testers?

Requested: CMI8330 testers?

[Takashi Iwai]

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

Hi,

can anyone who owns the CMI8330 ISA test the attached patch?
the patch will change the pcm interface of this soundchip as a more
reasonable way.  the playback and capture are combined into one pcm.
it's for the latest cvs version.  not sure whether it's applicable to
rc6.

please check whether the full-duplex works.  it's enough to run aplay
and arecord simultaneously.


thanks,

Takashi

[-- Attachment #2: cmi8330-pcm-fix.dif --]
[-- Type: application/octet-stream, Size: 11118 bytes --]

Index: alsa-kernel/core/pcm.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/core/pcm.c,v
retrieving revision 1.20
diff -u -r1.20 pcm.c
--- alsa-kernel/core/pcm.c	4 Dec 2002 09:37:21 -0000	1.20
+++ alsa-kernel/core/pcm.c	16 Dec 2002 14:04:21 -0000
@@ -774,6 +774,7 @@
 	runtime->status->state = SNDRV_PCM_STATE_OPEN;
 
 	substream->runtime = runtime;
+	substream->private_data = pcm->private_data;
 	pstr->substream_opened++;
 	*rsubstream = substream;
 	return 0;
Index: alsa-kernel/include/ad1848.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/include/ad1848.h,v
retrieving revision 1.4
diff -u -r1.4 ad1848.h
--- alsa-kernel/include/ad1848.h	13 Aug 2002 16:17:06 -0000	1.4
+++ alsa-kernel/include/ad1848.h	16 Dec 2002 14:35:52 -0000
@@ -162,6 +162,7 @@
 		      ad1848_t ** chip);
 
 int snd_ad1848_pcm(ad1848_t * chip, int device, snd_pcm_t **rpcm);
+const snd_pcm_ops_t *snd_ad1848_get_pcm_ops(int direction);
 int snd_ad1848_mixer(ad1848_t * chip);
 void snd_ad1848_interrupt(int irq, void *dev_id, struct pt_regs *regs);
 
Index: alsa-kernel/include/pcm.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/include/pcm.h,v
retrieving revision 1.21
diff -u -r1.21 pcm.h
--- alsa-kernel/include/pcm.h	2 Dec 2002 09:25:18 -0000	1.21
+++ alsa-kernel/include/pcm.h	16 Dec 2002 14:03:06 -0000
@@ -50,7 +50,7 @@
 typedef struct sndrv_pcm_mmap_control snd_pcm_mmap_control_t;
 typedef struct sndrv_mask snd_mask_t;
 
-#define _snd_pcm_substream_chip(substream) ((substream)->pcm->private_data)
+#define _snd_pcm_substream_chip(substream) ((substream)->private_data)
 #define snd_pcm_substream_chip(substream) snd_magic_cast1(chip_t, _snd_pcm_substream_chip(substream), return -ENXIO)
 #define _snd_pcm_chip(pcm) ((pcm)->private_data)
 #define snd_pcm_chip(pcm) snd_magic_cast1(chip_t, _snd_pcm_chip(pcm), return -ENXIO)
@@ -363,6 +363,7 @@
 struct _snd_pcm_substream {
 	snd_pcm_t *pcm;
 	snd_pcm_str_t *pstr;
+	void *private_data;		/* copied from pcm->private_data */
 	int number;
 	char name[32];			/* substream name */
 	int stream;			/* stream (direction) */
Index: alsa-kernel/include/sb.h
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/include/sb.h,v
retrieving revision 1.7
diff -u -r1.7 sb.h
--- alsa-kernel/include/sb.h	9 Dec 2002 10:52:24 -0000	1.7
+++ alsa-kernel/include/sb.h	16 Dec 2002 14:36:01 -0000
@@ -305,6 +305,7 @@
 
 /* sb16_init.c */
 int snd_sb16dsp_pcm(sb_t *chip, int device, snd_pcm_t ** rpcm);
+const snd_pcm_ops_t *snd_sb16dsp_get_pcm_ops(int direction);
 int snd_sb16dsp_configure(sb_t *chip);
 /* sb16.c */
 void snd_sb16dsp_interrupt(int irq, void *dev_id, struct pt_regs *regs);
Index: alsa-kernel/isa/cmi8330.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/cmi8330.c,v
retrieving revision 1.10
diff -u -r1.10 cmi8330.c
--- alsa-kernel/isa/cmi8330.c	22 Oct 2002 09:37:24 -0000	1.10
+++ alsa-kernel/isa/cmi8330.c	16 Dec 2002 15:01:19 -0000
@@ -147,6 +147,15 @@
 	struct isapnp_dev *cap;
 	struct isapnp_dev *play;
 #endif
+	snd_card_t *card;
+	ad1848_t *wss;
+	sb_t *sb;
+
+	snd_pcm_t *pcm;
+	snd_pcm_ops_t playback_ops;
+	int (*playback_open)(snd_pcm_substream_t *);
+	snd_pcm_ops_t capture_ops;
+	int (*capture_open)(snd_pcm_substream_t *);
 };
 
 static snd_card_t *snd_cmi8330_cards[SNDRV_CARDS] = SNDRV_DEFAULT_PTR;
@@ -294,6 +303,79 @@
 }
 #endif
 
+/*
+ * PCM interface
+ *
+ * since we call the different chip interfaces for playback and capture
+ * directions, we need a trick.
+ *
+ * - copy the ops for each direction into a local record.
+ * - replace the open callback with the new one, which replaces the
+ *   substream->private_data with the corresponding chip instance
+ *   and calls again the original open callback of the chip.
+ *
+ */
+
+static int snd_cmi8330_playback_open(snd_pcm_substream_t * substream)
+{
+	struct snd_cmi8330 *chip = (struct snd_cmi8330 *)_snd_pcm_substream_chip(substream);
+
+	/* replace the private_data and call the original open callback */
+	substream->private_data = chip->sb;
+	return chip->playback_open(substream);
+}
+
+static int snd_cmi8330_capture_open(snd_pcm_substream_t * substream)
+{
+	struct snd_cmi8330 *chip = (struct snd_cmi8330 *)_snd_pcm_substream_chip(substream);
+
+	/* replace the private_data and call the original open callback */
+	substream->private_data = chip->wss;
+	return chip->capture_open(substream);
+}
+
+static void snd_cmi8330_pcm_free(snd_pcm_t *pcm)
+{
+	snd_pcm_lib_preallocate_free_for_all(pcm);
+}
+
+static int __init snd_cmi8330_pcm(snd_card_t *card, struct snd_cmi8330 *chip)
+{
+	snd_pcm_t *pcm;
+	const snd_pcm_ops_t *ops;
+	int err;
+	
+	if ((err = snd_pcm_new(card, "CMI8330", 0, 1, 1, &pcm)) < 0)
+		return err;
+	strcpy(pcm->name, "CMI8330");
+	pcm->private_data = chip;
+	pcm->private_free = snd_cmi8330_pcm_free;
+	
+	/* playback - SB16 */
+	ops = snd_sb16dsp_get_pcm_ops(SNDRV_PCM_STREAM_PLAYBACK);
+	chip->playback_ops = *ops;
+	chip->playback_open = ops->open;
+	chip->playback_ops.open = snd_cmi8330_playback_open;
+
+	/* capture - AD1848 */
+	ops = snd_ad1848_get_pcm_ops(SNDRV_PCM_STREAM_CAPTURE);
+	chip->capture_ops = *ops;
+	chip->capture_open = ops->open;
+	chip->capture_ops.open = snd_cmi8330_capture_open;
+
+	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &chip->playback_ops);
+	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &chip->capture_ops);
+
+	snd_pcm_lib_preallocate_isa_pages_for_all(pcm, 64*1024, 128*1024);
+	chip->pcm = pcm;
+
+	return 0;
+}
+
+
+/*
+ */
+
 static void snd_cmi8330_free(snd_card_t *card)
 {
 	struct snd_cmi8330 *acard = (struct snd_cmi8330 *)card->private_data;
@@ -309,12 +391,8 @@
 {
 	snd_card_t *card;
 	struct snd_cmi8330 *acard;
-	ad1848_t *chip_wss;
-	sb_t *chip_sb;
 	unsigned long flags;
 	int i, err;
-	snd_pcm_t *pcm, *wss_pcm, *sb_pcm;
-	snd_pcm_str_t *pstr;
 
 #ifdef __ISAPNP__
 	if (!isapnp[dev]) {
@@ -337,6 +415,7 @@
 		return -ENOMEM;
 	}
 	acard = (struct snd_cmi8330 *)card->private_data;
+	acard->card = card;
 	card->private_free = snd_cmi8330_free;
 
 #ifdef __ISAPNP__
@@ -352,83 +431,60 @@
 				     wssirq[dev],
 				     wssdma[dev],
 				     AD1848_HW_DETECT,
-				     &chip_wss)) < 0) {
+				     &acard->wss)) < 0) {
 		snd_printk("(AD1848) device busy??\n");
 		snd_card_free(card);
 		return err;
 	}
-	if (chip_wss->hardware != AD1848_HW_CMI8330) {
+	if (acard->wss->hardware != AD1848_HW_CMI8330) {
 		snd_printk("(AD1848) not found during probe\n");
 		snd_card_free(card);
 		return -ENODEV;
 	}
-	if ((err = snd_ad1848_pcm(chip_wss, 0, &wss_pcm)) < 0) {
-		snd_printk("(AD1848) no enough memory??\n");
-		snd_card_free(card);
-		return err;
-	}
 
 	if ((err = snd_sbdsp_create(card, sbport[dev],
 				    sbirq[dev],
 				    snd_sb16dsp_interrupt,
 				    sbdma8[dev],
 				    sbdma16[dev],
-				    SB_HW_AUTO, &chip_sb)) < 0) {
+				    SB_HW_AUTO, &acard->sb)) < 0) {
 		snd_printk("(SB16) device busy??\n");
 		snd_card_free(card);
 		return err;
 	}
-	if ((err = snd_sb16dsp_pcm(chip_sb, 1, &sb_pcm)) < 0) {
-		snd_printk("(SB16) no enough memory??\n");
-		snd_card_free(card);
-		return err;
-	}
-
-	if (chip_sb->hardware != SB_HW_16) {
+	if (acard->sb->hardware != SB_HW_16) {
 		snd_printk("(SB16) not found during probe\n");
 		snd_card_free(card);
 		return -ENODEV;
 	}
+	memcpy(&acard->wss->image[16], &snd_cmi8330_image, sizeof(snd_cmi8330_image));
 
-	memcpy(&chip_wss->image[16], &snd_cmi8330_image, sizeof(snd_cmi8330_image));
+	spin_lock_irqsave(&acard->wss->reg_lock, flags);
+	snd_ad1848_out(acard->wss, AD1848_MISC_INFO,	/* switch on MODE2 */
+		       acard->wss->image[AD1848_MISC_INFO] |= 0x40);
+	spin_unlock_irqrestore(&acard->wss->reg_lock, flags);
 
-	spin_lock_irqsave(&chip_wss->reg_lock, flags);
-	snd_ad1848_out(chip_wss, AD1848_MISC_INFO,	/* switch on MODE2 */
-		       chip_wss->image[AD1848_MISC_INFO] |= 0x40);
-	spin_unlock_irqrestore(&chip_wss->reg_lock, flags);
-
-	if ((err = snd_cmi8330_mixer(card, chip_wss)) < 0) {
+	if ((err = snd_cmi8330_mixer(card, acard->wss)) < 0) {
 		snd_printk("failed to create mixers\n");
 		snd_card_free(card);
 		return err;
 	}
-	spin_lock_irqsave(&chip_wss->reg_lock, flags);
+	spin_lock_irqsave(&acard->wss->reg_lock, flags);
 	for (i = CMI8330_RMUX3D; i <= CMI8330_CDINGAIN; i++)
-		snd_ad1848_out(chip_wss, i, chip_wss->image[i]);
-	spin_unlock_irqrestore(&chip_wss->reg_lock, flags);
+		snd_ad1848_out(acard->wss, i, acard->wss->image[i]);
+	spin_unlock_irqrestore(&acard->wss->reg_lock, flags);
 
-	/*
-	 * KLUDGE ALERT
-	 *  disable AD1848 playback
-	 *  disable SB16 capture
-	 */
-	pcm = wss_pcm;
-	pstr = &pcm->streams[SNDRV_PCM_STREAM_PLAYBACK];
-	snd_magic_kfree(pstr->substream);
-	pstr->substream = 0;
-	pstr->substream_count = 0;
-
-	pcm = sb_pcm;
-	pstr = &pcm->streams[SNDRV_PCM_STREAM_CAPTURE];
-	snd_magic_kfree(pstr->substream);
-	pstr->substream = 0;
-	pstr->substream_count = 0;
+	if ((err = snd_cmi8330_pcm(card, acard)) < 0) {
+		snd_printk("failed to create pcms\n");
+		snd_card_free(card);
+		return err;
+	}
 
 	strcpy(card->driver, "CMI8330/C3D");
 	strcpy(card->shortname, "C-Media CMI8330/C3D");
 	sprintf(card->longname, "%s at 0x%lx, irq %d, dma %d",
-		wss_pcm->name,
-		chip_wss->port,
+		card->shortname,
+		acard->wss->port,
 		wssirq[dev],
 		wssdma[dev]);
 
Index: alsa-kernel/isa/ad1848/ad1848_lib.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/ad1848/ad1848_lib.c,v
retrieving revision 1.17
diff -u -r1.17 ad1848_lib.c
--- alsa-kernel/isa/ad1848/ad1848_lib.c	25 Nov 2002 10:13:55 -0000	1.17
+++ alsa-kernel/isa/ad1848/ad1848_lib.c	16 Dec 2002 14:35:39 -0000
@@ -936,6 +936,12 @@
 	return 0;
 }
 
+const snd_pcm_ops_t *snd_ad1848_get_pcm_ops(int direction)
+{
+	return direction == SNDRV_PCM_STREAM_PLAYBACK ?
+		&snd_ad1848_playback_ops : &snd_ad1848_capture_ops;
+}
+
 /*
  *  MIXER part
  */
@@ -1160,6 +1166,7 @@
 EXPORT_SYMBOL(snd_ad1848_interrupt);
 EXPORT_SYMBOL(snd_ad1848_create);
 EXPORT_SYMBOL(snd_ad1848_pcm);
+EXPORT_SYMBOL(snd_ad1848_get_pcm_ops);
 EXPORT_SYMBOL(snd_ad1848_mixer);
 EXPORT_SYMBOL(snd_ad1848_info_single);
 EXPORT_SYMBOL(snd_ad1848_get_single);
Index: alsa-kernel/isa/sb/sb16_main.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/sb/sb16_main.c,v
retrieving revision 1.11
diff -u -r1.11 sb16_main.c
--- alsa-kernel/isa/sb/sb16_main.c	25 Nov 2002 10:13:56 -0000	1.11
+++ alsa-kernel/isa/sb/sb16_main.c	16 Dec 2002 14:35:02 -0000
@@ -887,7 +887,14 @@
 	return 0;
 }
 
+const snd_pcm_ops_t *snd_sb16dsp_get_pcm_ops(int direction)
+{
+	return direction == SNDRV_PCM_STREAM_PLAYBACK ?
+		&snd_sb16_playback_ops : &snd_sb16_capture_ops;
+}
+
 EXPORT_SYMBOL(snd_sb16dsp_pcm);
+EXPORT_SYMBOL(snd_sb16dsp_get_pcm_ops);
 EXPORT_SYMBOL(snd_sb16dsp_configure);
 EXPORT_SYMBOL(snd_sb16dsp_interrupt);
 

Re: Requested: CMI8330 testers?

[Bernard Urban]

Takashi Iwai <tiwai@suse.de> writes:

> Hi,
> 
> can anyone who owns the CMI8330 ISA test the attached patch?

I am your man !!! Happy to see that this card is no longer forgotten.
1 month ago, I have written the following to
alsa-devel@lists.sourceforge.net, but it never got there (I was not a
subscriber at this time). 

******************************************

Short story: (and main problem)
=========
I have tried to hack the cmi8330 driver version 0.9.0beta10, which 
does not work, by relying on the (semi) functional last 0.5 driver. It
is difficult to appreciate the changes done between 0.5 and 0.9,
as the CVS Changelog misses the 0.5 era.
Any hint to fill this hole would be appreciated.

More generally, I am wondering if ALSA is still considering
maintenance on old sound chips drivers?
As an alsa-1.0 release is near, this topic seems important to the
credibility of the project. 

Long story: (plus a lot of other minor problems)
=========
I have access to 4 different Linux machines, with different sound
cards. All the machine run Debian Woody, kernel 2.4.18, 
same config for 4 machines, as far as hardware permits: 
AMD K6-II with a SB Vibra 16x PnP
AMD K6-II with a CMI8330
PIII with a intel 810
Athlon with a VIA8233

First, the two K6-II machines run fine the OSS sb driver.
When I got the Athlon machines, as via8233 is not supported by OSS
drivers, I decided to switch to ALSA 0.9 (woody packages 0.9.0beta12). 

The Athlon with snd-via8233 runs fine, no problems with using the OSS
compatibility level.
The PIII with snd-intel8x0 runs well, except that xquake (original bin
from Id) runs without producing any sound. Moot point, because
quakeforge version works well (alsa plugin).

So the problem here seems to be in the oss compatibility level ?

Now the AMD K6-II with a SB Vibra 16X PnP: runs with snd-sb16. In the
mixer I must force the 16 bit DMA to be allocated to Capture 
to have PCM sound for all kind of audio formats. If set to Auto, for instance
.au format is not recognized. Also, xquake runs and  produces sound only with
option 8bits sound. quakeforge works well, but there is a time lag in
producing sound, which does not exist with the OSS driver. 
Tuning snd-mixahead does not help. 

Finally the AMD K6-II with the CMI8330 and the snd-cmi8330 driver.
Version 0.9 does not produce sound at all. But going back to alsa 0.5,
I was able to produce PCM sound and play CDs. The mixer tuning is very
buggy (this was documented in the alsa-user mail list 2 years ago!), 
but you can have it working. xquake does not produce sound though.
quakeforge cannot be run (they use the 0.9 alsa API).

Another real pain with this driver is the use of
two devices (pcmC0D1p and pcmC0d0c) on the same card. This requires
editing several configuration files to have OSS applications work.
For instance, I must switch /dev/dsp with /dev/adsp and change in
alsa.conf to the following line:
defaults.pcm.device 1

This was corrected in the 0.9 snd-cmi8330 driver, but as it now does not
produce sound... I have analyzed the driver code differences between
0.5 and 0.9. The main difference in handling the hardware seems to be that
in the 0.5 version, the SB mixer part is initialized, not in the 0.9
one. So I added such an initialization step. I added also the SB mixer
controls to the cmi8330 ones, as it is no more possible to add a second
mixer device in the 0.9 API, at least I do not see how. 
(This addition is not understood
by alsamixer, but amixer with the complex controls works, with the
same kind of curious behaviour as amixer-0.5)

And guess what, bingo, I got PCM sound ! But an horrible sound, very
distorted, so something is still working badly. This
was just after removing the 0.5 driver and installing the modified 0.9 one.
After rebooting the machine with the 0.9 running, no more sound!

So there is obviously something which has not been initialized well in
the 0.9 driver alone. I have also tried to suppress completely any
handling of the SB part (mixer + PCM), or only resetting it, to no avail so far.

As sb16 and cmi8330 are now old chips, I am wondering if there is
today any action on the corresponding drivers more than "edit the driver file
source to make it compile if there is an API change".

***************************************

Meanwhile, I have started to read your document "Writing an Alsa
driver". This explains a lot of things, and fills a huge hole in the
Alsa project, thanks ! 

> the patch will change the pcm interface of this soundchip as a more
> reasonable way.  the playback and capture are combined into one pcm.
> it's for the latest cvs version.  not sure whether it's applicable to
> rc6.
> 
> please check whether the full-duplex works.  it's enough to run aplay
> and arecord simultaneously.

I hope to be able to test your patch for next Monday.

Regards.

-- 

Bernard Urban


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

Re: Requested: CMI8330 testers?

[Takashi Iwai]

Hi Bernard,

thanks for your reply.

At 27 Dec 2002 10:19:10 +0100,
Bernard Urban wrote:
> 
> Takashi Iwai <tiwai@suse.de> writes:
> 
> > Hi,
> > 
> > can anyone who owns the CMI8330 ISA test the attached patch?
> 
> I am your man !!! Happy to see that this card is no longer forgotten.
> 1 month ago, I have written the following to
> alsa-devel@lists.sourceforge.net, but it never got there (I was not a
> subscriber at this time). 
> 
> ******************************************
> 
> Short story: (and main problem)
> =========
> I have tried to hack the cmi8330 driver version 0.9.0beta10, which 
> does not work, by relying on the (semi) functional last 0.5 driver. It
> is difficult to appreciate the changes done between 0.5 and 0.9,
> as the CVS Changelog misses the 0.5 era.
> Any hint to fill this hole would be appreciated.
> 
> More generally, I am wondering if ALSA is still considering
> maintenance on old sound chips drivers?

we can maintain the code but none of us have these hardwares for
test...

> As an alsa-1.0 release is near, this topic seems important to the
> credibility of the project. 
> 
> Long story: (plus a lot of other minor problems)
> =========
> I have access to 4 different Linux machines, with different sound
> cards. All the machine run Debian Woody, kernel 2.4.18, 
> same config for 4 machines, as far as hardware permits: 
> AMD K6-II with a SB Vibra 16x PnP
> AMD K6-II with a CMI8330
> PIII with a intel 810
> Athlon with a VIA8233
> 
> First, the two K6-II machines run fine the OSS sb driver.
> When I got the Athlon machines, as via8233 is not supported by OSS
> drivers, I decided to switch to ALSA 0.9 (woody packages 0.9.0beta12). 
> 
> The Athlon with snd-via8233 runs fine, no problems with using the OSS
> compatibility level.
> The PIII with snd-intel8x0 runs well, except that xquake (original bin
> from Id) runs without producing any sound. Moot point, because
> quakeforge version works well (alsa plugin).
> 
> So the problem here seems to be in the oss compatibility level ?
 
most likely the problem is due to mmap on OSS emulation.
the OSS emulation should be "direct" mode in some cases.
you can change the behavior via writing to oss proc file like

   echo "xquake 0 0 direct" > /proc/asound/card0/pcm0p/oss

please check alsa-kernel/Documentation/ALSA-Configuration.txt for
details.


> Now the AMD K6-II with a SB Vibra 16X PnP: runs with snd-sb16. In the
> mixer I must force the 16 bit DMA to be allocated to Capture 
> to have PCM sound for all kind of audio formats. If set to Auto, for instance
> .au format is not recognized. Also, xquake runs and  produces sound only with
> option 8bits sound.

perhaps this is also related with the above.

> quakeforge works well, but there is a time lag in
> producing sound, which does not exist with the OSS driver. 
> Tuning snd-mixahead does not help. 
 
this is not sure.  does the delay happen only on quake or do you mean
it generally?  if it's general behavior, then it's easier to debug.
anyway we need to trace at which point the delay occurs.

> Finally the AMD K6-II with the CMI8330 and the snd-cmi8330 driver.
> Version 0.9 does not produce sound at all. But going back to alsa 0.5,
> I was able to produce PCM sound and play CDs. The mixer tuning is very
> buggy (this was documented in the alsa-user mail list 2 years ago!), 
> but you can have it working. xquake does not produce sound though.
> quakeforge cannot be run (they use the 0.9 alsa API).
> 
> Another real pain with this driver is the use of
> two devices (pcmC0D1p and pcmC0d0c) on the same card. This requires
> editing several configuration files to have OSS applications work.
> For instance, I must switch /dev/dsp with /dev/adsp and change in
> alsa.conf to the following line:
> defaults.pcm.device 1
> 
> This was corrected in the 0.9 snd-cmi8330 driver, but as it now does not
> produce sound... I have analyzed the driver code differences between
> 0.5 and 0.9. The main difference in handling the hardware seems to be that
> in the 0.5 version, the SB mixer part is initialized, not in the 0.9
> one. So I added such an initialization step. I added also the SB mixer
> controls to the cmi8330 ones, as it is no more possible to add a second
> mixer device in the 0.9 API, at least I do not see how. 
> (This addition is not understood
> by alsamixer, but amixer with the complex controls works, with the
> same kind of curious behaviour as amixer-0.5)

well, the mixers are all mixed up on alsa 0.9.  it's possible to
assign the ad1848 mixer elements with the index 1, though.

> And guess what, bingo, I got PCM sound ! But an horrible sound, very
> distorted, so something is still working badly. This
> was just after removing the 0.5 driver and installing the modified 0.9 one.
> After rebooting the machine with the 0.9 running, no more sound!
 
ok, it explains the hardware init problem.
i'll check the difference between 0.5 and 0.9.


btw, my last patch was already committed to cvs.


ciao,

Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Requested: CMI8330 testers?

[Takashi Iwai]

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

Hi, it's me again.

At Wed, 08 Jan 2003 14:00:03 +0100,
I wrote:
> 
> > And guess what, bingo, I got PCM sound ! But an horrible sound, very
> > distorted, so something is still working badly. This
> > was just after removing the 0.5 driver and installing the modified 0.9 one.
> > After rebooting the machine with the 0.9 running, no more sound!
>  
> ok, it explains the hardware init problem.
> i'll check the difference between 0.5 and 0.9.

please try the attached patch.
it will add the SB mixers (all new ones starting "SB xxx" except for
tone controls) and initializes the SB-mixer reg bit (as default).

the first step is to check whether and which SB mixer has influence to
what output/input.  there are also CMI8330-native controls, namely the
controls without "SB" prefix.  whether these controls affect the
playback.  the SB mixers can be disabled (removed) by commenting out
ENABLE_SB_MIXER definition in the source.

the next step is to switch playback and capture by commenting out the
definition PLAYBACK_ON_SB at the beginning of the code.  then the
playback will be done through AD1848 and capture will be on SB16.
check again which mixer elements work for what.


ciao,

Takashi

[-- Attachment #2: cmi8330-test.dif --]
[-- Type: application/octet-stream, Size: 10517 bytes --]

Index: alsa-kernel/isa/cmi8330.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/cmi8330.c,v
retrieving revision 1.11
diff -u -r1.11 cmi8330.c
--- alsa-kernel/isa/cmi8330.c	7 Jan 2003 10:29:35 -0000	1.11
+++ alsa-kernel/isa/cmi8330.c	8 Jan 2003 16:13:30 -0000
@@ -57,6 +57,13 @@
 #define SNDRV_GET_ID
 #include <sound/initval.h>
 
+/*
+ */
+#define ENABLE_SB_MIXER
+#define PLAYBACK_ON_SB
+
+/*
+ */
 MODULE_AUTHOR("George Talusan <gstalusan@uwaterloo.ca>");
 MODULE_DESCRIPTION("C-Media CMI8330");
 MODULE_LICENSE("GPL");
@@ -129,8 +136,12 @@
 
 static unsigned char snd_cmi8330_image[((CMI8330_CDINGAIN)-16) + 1] =
 {
-	0x0,			/* 16 - recording mux */
-	0x40,			/* 17 - mute mux */
+	0x40,			/* 16 - recording mux (SB-mixer-enabled) */
+#ifdef ENABLE_SB_MIXER
+	0x40,			/* 17 - mute mux (Mode2) */
+#else
+	0x0,			/* 17 - mute mux */
+#endif
 	0x0,			/* 18 - vol */
 	0x0,			/* 19 - master volume */
 	0x0,			/* 20 - line-in volume */
@@ -152,10 +163,11 @@
 	sb_t *sb;
 
 	snd_pcm_t *pcm;
-	snd_pcm_ops_t playback_ops;
-	int (*playback_open)(snd_pcm_substream_t *);
-	snd_pcm_ops_t capture_ops;
-	int (*capture_open)(snd_pcm_substream_t *);
+	struct snd_cmi8330_stream {
+		snd_pcm_ops_t ops;
+		int (*open)(snd_pcm_substream_t *);
+		void *private_data; /* sb or wss */
+	} streams[2];
 };
 
 static snd_card_t *snd_cmi8330_cards[SNDRV_CARDS] = SNDRV_DEFAULT_PTR;
@@ -210,6 +222,24 @@
 AD1848_SINGLE("FM Playback Switch", 0, CMI8330_RECMUX, 3, 1, 1),
 AD1848_SINGLE("IEC958 Input Capture Switch", 0, CMI8330_RMUX3D, 7, 1, 1),
 AD1848_SINGLE("IEC958 Input Playback Switch", 0, CMI8330_MUTEMUX, 7, 1, 1),
+
+#ifdef ENABLE_SB_MIXER
+SB_DOUBLE("SB Master Playback Volume", SB_DSP4_MASTER_DEV, (SB_DSP4_MASTER_DEV + 1), 3, 3, 31),
+SB_DOUBLE("Tone Control - Bass", SB_DSP4_BASS_DEV, (SB_DSP4_BASS_DEV + 1), 4, 4, 15),
+SB_DOUBLE("Tone Control - Treble", SB_DSP4_TREBLE_DEV, (SB_DSP4_TREBLE_DEV + 1), 4, 4, 15),
+SB_DOUBLE("SB PCM Playback Volume", SB_DSP4_PCM_DEV, (SB_DSP4_PCM_DEV + 1), 3, 3, 31),
+SB_DOUBLE("SB Synth Playback Volume", SB_DSP4_SYNTH_DEV, (SB_DSP4_SYNTH_DEV + 1), 3, 3, 31),
+SB_DOUBLE("SB CD Playback Switch", SB_DSP4_OUTPUT_SW, SB_DSP4_OUTPUT_SW, 2, 1, 1),
+SB_DOUBLE("SB CD Playback Volume", SB_DSP4_CD_DEV, (SB_DSP4_CD_DEV + 1), 3, 3, 31),
+SB_DOUBLE("SB Line Playback Switch", SB_DSP4_OUTPUT_SW, SB_DSP4_OUTPUT_SW, 4, 3, 1),
+SB_DOUBLE("SB Line Playback Volume", SB_DSP4_LINE_DEV, (SB_DSP4_LINE_DEV + 1), 3, 3, 31),
+SB_SINGLE("SB Mic Playback Switch", SB_DSP4_OUTPUT_SW, 0, 1),
+SB_SINGLE("SB Mic Playback Volume", SB_DSP4_MIC_DEV, 3, 31),
+SB_SINGLE("SB PC Speaker Volume", SB_DSP4_SPEAKER_DEV, 6, 3),
+SB_DOUBLE("SB Capture Volume", SB_DSP4_IGAIN_DEV, (SB_DSP4_IGAIN_DEV + 1), 6, 6, 3),
+SB_DOUBLE("SB Playback Volume", SB_DSP4_OGAIN_DEV, (SB_DSP4_OGAIN_DEV + 1), 6, 6, 3),
+SB_SINGLE("SB Mic Auto Gain", SB_DSP4_MIC_AGC, 0, 1),
+#endif
 };
 
 static int __init snd_cmi8330_mixer(snd_card_t *card, ad1848_t *chip)
@@ -316,13 +346,21 @@
  *
  */
 
+#ifdef PLAYBACK_ON_SB
+#define CMI_SB_STREAM	SNDRV_PCM_STREAM_PLAYBACK
+#define CMI_AD_STREAM	SNDRV_PCM_STREAM_CAPTURE
+#else
+#define CMI_SB_STREAM	SNDRV_PCM_STREAM_CAPTURE
+#define CMI_AD_STREAM	SNDRV_PCM_STREAM_PLAYBACK
+#endif
+
 static int snd_cmi8330_playback_open(snd_pcm_substream_t * substream)
 {
 	struct snd_cmi8330 *chip = (struct snd_cmi8330 *)_snd_pcm_substream_chip(substream);
 
 	/* replace the private_data and call the original open callback */
-	substream->private_data = chip->sb;
-	return chip->playback_open(substream);
+	substream->private_data = chip->streams[SNDRV_PCM_STREAM_PLAYBACK].private_data;
+	return chip->streams[SNDRV_PCM_STREAM_PLAYBACK].open(substream);
 }
 
 static int snd_cmi8330_capture_open(snd_pcm_substream_t * substream)
@@ -330,8 +368,8 @@
 	struct snd_cmi8330 *chip = (struct snd_cmi8330 *)_snd_pcm_substream_chip(substream);
 
 	/* replace the private_data and call the original open callback */
-	substream->private_data = chip->wss;
-	return chip->capture_open(substream);
+	substream->private_data = chip->streams[SNDRV_PCM_STREAM_CAPTURE].private_data;
+	return chip->streams[SNDRV_PCM_STREAM_CAPTURE].open(substream);
 }
 
 static void snd_cmi8330_pcm_free(snd_pcm_t *pcm)
@@ -344,27 +382,33 @@
 	snd_pcm_t *pcm;
 	const snd_pcm_ops_t *ops;
 	int err;
-	
+	static int (*cmi_open_callbacks)(snd_pcm_substream_t *)[2] = {
+		snd_cmi8330_playback_open,
+		snd_cmi8330_capture_open
+	};
+
 	if ((err = snd_pcm_new(card, "CMI8330", 0, 1, 1, &pcm)) < 0)
 		return err;
 	strcpy(pcm->name, "CMI8330");
 	pcm->private_data = chip;
 	pcm->private_free = snd_cmi8330_pcm_free;
 	
-	/* playback - SB16 */
-	ops = snd_sb16dsp_get_pcm_ops(SNDRV_PCM_STREAM_PLAYBACK);
-	chip->playback_ops = *ops;
-	chip->playback_open = ops->open;
-	chip->playback_ops.open = snd_cmi8330_playback_open;
-
-	/* capture - AD1848 */
-	ops = snd_ad1848_get_pcm_ops(SNDRV_PCM_STREAM_CAPTURE);
-	chip->capture_ops = *ops;
-	chip->capture_open = ops->open;
-	chip->capture_ops.open = snd_cmi8330_capture_open;
+	/* SB16 */
+	ops = snd_sb16dsp_get_pcm_ops(CMI_SB_STREAM);
+	chip->streams[CMI_SB_STREAM].ops = *ops;
+	chip->streams[CMI_SB_STREAM].open = ops->open;
+	chip->streams[CMI_SB_STREAM].ops.open = cmi_open_callbacks[CMI_SB_STREAM];
+	chip->streams[CMI_SB_STREAM].private_data = chip->sb;
+
+	/* AD1848 */
+	ops = snd_ad1848_get_pcm_ops(CMI_AD_STREAM);
+	chip->streams[CMI_AD_STREAM].ops = *ops;
+	chip->streams[CMI_AD_STREAM].open = ops->open;
+	chip->streams[CMI_AD_STREAM].ops.open = cmi_open_callbacks[CMI_AD_STREAM];
+	chip->streams[CMI_AD_STREAM].private_data = chip->wss;
 
-	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &chip->playback_ops);
-	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &chip->capture_ops);
+	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &chip->streams[SNDRV_PCM_STREAM_PLAYBACK].ops);
+	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &chip->streams[SNDRV_PCM_STREAM_CAPTURE].ops);
 
 	snd_pcm_lib_preallocate_isa_pages_for_all(pcm, 64*1024, 128*1024);
 	chip->pcm = pcm;
@@ -457,11 +501,11 @@
 		snd_card_free(card);
 		return -ENODEV;
 	}
-	memcpy(&acard->wss->image[16], &snd_cmi8330_image, sizeof(snd_cmi8330_image));
 
 	spin_lock_irqsave(&acard->wss->reg_lock, flags);
-	snd_ad1848_out(acard->wss, AD1848_MISC_INFO,	/* switch on MODE2 */
-		       acard->wss->image[AD1848_MISC_INFO] |= 0x40);
+	snd_ad1848_out(acard->wss, AD1848_MISC_INFO, 0x40); /* switch on MODE2 */
+	for (i = CMI8330_RMUX3D; i <= CMI8330_CDINGAIN; i++)
+		snd_ad1848_out(acard->wss, i, snd_cmi8330_image[i - CMI8330_RMUX3D]);
 	spin_unlock_irqrestore(&acard->wss->reg_lock, flags);
 
 	if ((err = snd_cmi8330_mixer(card, acard->wss)) < 0) {
@@ -469,10 +513,6 @@
 		snd_card_free(card);
 		return err;
 	}
-	spin_lock_irqsave(&acard->wss->reg_lock, flags);
-	for (i = CMI8330_RMUX3D; i <= CMI8330_CDINGAIN; i++)
-		snd_ad1848_out(acard->wss, i, acard->wss->image[i]);
-	spin_unlock_irqrestore(&acard->wss->reg_lock, flags);
 
 	if ((err = snd_cmi8330_pcm(card, acard)) < 0) {
 		snd_printk("failed to create pcms\n");
Index: alsa-kernel/isa/sb/sb_common.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/sb/sb_common.c,v
retrieving revision 1.14
diff -u -r1.14 sb_common.c
--- alsa-kernel/isa/sb/sb_common.c	25 Nov 2002 10:13:56 -0000	1.14
+++ alsa-kernel/isa/sb/sb_common.c	8 Jan 2003 15:58:00 -0000
@@ -298,6 +298,13 @@
 EXPORT_SYMBOL(snd_sbmixer_read);
 EXPORT_SYMBOL(snd_sbmixer_new);
 
+EXPORT_SYMBOL(snd_sbmixer_info_single);
+EXPORT_SYMBOL(snd_sbmixer_get_single);
+EXPORT_SYMBOL(snd_sbmixer_put_single);
+EXPORT_SYMBOL(snd_sbmixer_info_double);
+EXPORT_SYMBOL(snd_sbmixer_get_double);
+EXPORT_SYMBOL(snd_sbmixer_put_double);
+
 /*
  *  INIT part
  */
Index: alsa-kernel/isa/sb/sb_mixer.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/sb/sb_mixer.c,v
retrieving revision 1.9
diff -u -r1.9 sb_mixer.c
--- alsa-kernel/isa/sb/sb_mixer.c	7 Jan 2003 10:39:16 -0000	1.9
+++ alsa-kernel/isa/sb/sb_mixer.c	8 Jan 2003 15:57:24 -0000
@@ -60,15 +60,7 @@
  * Single channel mixer element
  */
 
-#define SB_SINGLE(xname, reg, shift, mask) \
-{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, \
-  .name = xname, \
-  .info = snd_sbmixer_info_single, \
-  .get = snd_sbmixer_get_single, \
-  .put = snd_sbmixer_put_single, \
-  .private_value = reg | (shift << 16) | (mask << 24) }
-
-static int snd_sbmixer_info_single(snd_kcontrol_t *kcontrol, snd_ctl_elem_info_t * uinfo)
+int snd_sbmixer_info_single(snd_kcontrol_t *kcontrol, snd_ctl_elem_info_t * uinfo)
 {
 	int mask = (kcontrol->private_value >> 24) & 0xff;
 
@@ -79,7 +71,7 @@
 	return 0;
 }
 
-static int snd_sbmixer_get_single(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
+int snd_sbmixer_get_single(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
 {
 	sb_t *sb = snd_kcontrol_chip(kcontrol);
 	unsigned long flags;
@@ -95,7 +87,7 @@
 	return 0;
 }
 
-static int snd_sbmixer_put_single(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
+int snd_sbmixer_put_single(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
 {
 	sb_t *sb = snd_kcontrol_chip(kcontrol);
 	unsigned long flags;
@@ -120,15 +112,7 @@
  * Double channel mixer element
  */
 
-#define SB_DOUBLE(xname, left_reg, right_reg, left_shift, right_shift, mask) \
-{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, \
-  .name = xname, \
-  .info = snd_sbmixer_info_double, \
-  .get = snd_sbmixer_get_double, \
-  .put = snd_sbmixer_put_double, \
-  .private_value = left_reg | (right_reg << 8) | (left_shift << 16) | (right_shift << 19) | (mask << 24) }
-
-static int snd_sbmixer_info_double(snd_kcontrol_t *kcontrol, snd_ctl_elem_info_t * uinfo)
+int snd_sbmixer_info_double(snd_kcontrol_t *kcontrol, snd_ctl_elem_info_t * uinfo)
 {
 	int mask = (kcontrol->private_value >> 24) & 0xff;
 
@@ -139,7 +123,7 @@
 	return 0;
 }
 
-static int snd_sbmixer_get_double(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
+int snd_sbmixer_get_double(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
 {
 	sb_t *sb = snd_kcontrol_chip(kcontrol);
 	unsigned long flags;
@@ -159,7 +143,7 @@
 	return 0;
 }
 
-static int snd_sbmixer_put_double(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
+int snd_sbmixer_put_double(snd_kcontrol_t * kcontrol, snd_ctl_elem_value_t * ucontrol)
 {
 	sb_t *sb = snd_kcontrol_chip(kcontrol);
 	unsigned long flags;

Re: Requested: CMI8330 testers?

[Takashi Iwai]

Hi,

At Wed, 08 Jan 2003 17:17:17 +0100,
I wrote:
> 
> please try the attached patch.
> it will add the SB mixers (all new ones starting "SB xxx" except for
> tone controls) and initializes the SB-mixer reg bit (as default).

i found the last patch including bugs.
now the new version was already applied to cvs, so just update the cvs
tree.

> 
> the first step is to check whether and which SB mixer has influence to
> what output/input.  there are also CMI8330-native controls, namely the
> controls without "SB" prefix.  whether these controls affect the
> playback.  the SB mixers can be disabled (removed) by commenting out
> ENABLE_SB_MIXER definition in the source.
> 
> the next step is to switch playback and capture by commenting out the
> definition PLAYBACK_ON_SB at the beginning of the code.  then the
> playback will be done through AD1848 and capture will be on SB16.
> check again which mixer elements work for what.

and please check the above again...


ciao,

Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: CMI8330: success !

[Bernard Urban]

Hello!

I will try to summarize my tests of the current (13 January) CVS tree
for this driver:

For playback, the following /etc/asound.state file works:

state.card0 {
	control.1 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 15'
		iface MIXER
		name 'Master Playback Volume'
		value.0 15
		value.1 15
	}
	control.2 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Loud Playback Switch'
		value true
	}
	control.3 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'PCM Playback Switch'
		value.0 true
		value.1 true
	}
	control.4 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 63'
		iface MIXER
		name 'PCM Playback Volume'
		value.0 63
		value.1 63
	}
	control.21 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name '3D Control - Switch'
		value true
	}
	control.22 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 3'
		iface MIXER
		name 'PC Speaker Playback Volume'
		value 0
	}
	control.23 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'FM Playback Switch'
		value true
	}
	control.24 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'IEC958 Input Capture Switch'
		value true
	}
	control.25 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'IEC958 Input Playback Switch'
		value true
	}
}
state.CARD_0 {
	control.1 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 15'
		iface MIXER
		name 'Master Playback Volume'
		value.0 15
		value.1 15
	}
	control.2 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'Loud Playback Switch'
		value true
	}
	control.3 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'PCM Playback Switch'
		value.0 true
		value.1 true
	}
	control.4 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 63'
		iface MIXER
		name 'PCM Playback Volume'
		value.0 61
		value.1 61
	}
	control.9 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'CD Playback Switch'
		value.0 true
		value.1 true
	}
	control.11 {
		comment.access 'read write'
		comment.type INTEGER
		comment.range '0 - 15'
		iface MIXER
		name 'CD Playback Volume'
		value.0 12
		value.1 12
	}
	control.21 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name '3D Control - Switch'
		value true
	}
	control.23 {
		comment.access 'read write'
		comment.type BOOLEAN
		iface MIXER
		name 'FM Playback Switch'
		value true
	}
}

Notice that I have deleted the controls with false or zero values to
save some place. For card0, the SB controls are absent. There are also
some differences between controls for card0 and CARD_0, why ? 
I get the CARD_0 controls when using alsamixer. 
The important thing to notice is that the SB
controls need not to be unmuted (as I first believe was necessary) ! 
So to have playback it is not needed
to define these SB controls in routine cmi8330_add_sb_mixers(). 
But the SB initialization step is probably mandatory (I will test it).

Actually, this is somehow curious, as PLAYBACK_ON_SB is defined, and
so playback should go through SB ??? It is apparently not the case.

Only one application did not work correctly, namely the old libc5
based xquake (yes, I have done
echo "xquake.real 0 0 direct" >/proc/asound/card0/pcm0p/oss).
There is sound, but extremely noisy.

Some words about the behaviour of the SB controls in alsamixer:
"SB" control follows the "SB Capture" control value.
"SB Synth", "SB PCM" and "SB Speaker" do not respond to commands.
"SB CD", "SB Line" and "SB Mic" cannot have values above 10%.

I have also tried both "SB Mic" and "Mic" controls in alsamixer, 
but capture did not work at all (only noise is registered and I have
Larsen effect when the volume is pushed too high). Nevertheless, 
as "SB Mic" cannot have values above 10%, here lies perhaps the 
problem.

I will now try to use #undefine  PLAYBACK_ON_SB.

Concerning the SB16 driver, I could not record either
(arecord is blocking indefinitly). Changing the 16 bits DMA control
did not help.

Regards.

-- 

Bernard Urban


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en

Re: CMI8330: success !

[Bernard Urban]

Bernard Urban <Bernard.Urban@meteo.fr> writes:
> 
> Notice that I have deleted the controls with false or zero values to
> save some place. For card0, the SB controls are absent. There are also
> some differences between controls for card0 and CARD_0, why ? 
> I get the CARD_0 controls when using alsamixer. 
> The important thing to notice is that the SB
> controls need not to be unmuted (as I first believe was necessary) ! 
> So to have playback it is not needed
> to define these SB controls in routine cmi8330_add_sb_mixers(). 
> But the SB initialization step is probably mandatory (I will test it).

Actually, the cmi8330 card works when undefining ENABLE_SB_MIXER.
So the init step in snd_sbdsp_create() is sufficient. This is good, as
you can get rid of these additional and dysfunctional controls.

> 
> Actually, this is somehow curious, as PLAYBACK_ON_SB is defined, and
> so playback should go through SB ??? It is apparently not the case.
> 
> Only one application did not work correctly, namely the old libc5
> based xquake (yes, I have done
> echo "xquake.real 0 0 direct" >/proc/asound/card0/pcm0p/oss).
> There is sound, but extremely noisy.
> 
> Some words about the behaviour of the SB controls in alsamixer:
> "SB" control follows the "SB Capture" control value.
> "SB Synth", "SB PCM" and "SB Speaker" do not respond to commands.
> "SB CD", "SB Line" and "SB Mic" cannot have values above 10%.
> 
> I have also tried both "SB Mic" and "Mic" controls in alsamixer, 
> but capture did not work at all (only noise is registered and I have
> Larsen effect when the volume is pushed too high). Nevertheless, 
> as "SB Mic" cannot have values above 10%, here lies perhaps the 
> problem.
> 
> I will now try to use #undefine  PLAYBACK_ON_SB.

This works also, with ENABLE_SB_MIXER defined, 
but some .wav files played on events in the desktop
are scratchy (sometimes, not always). So the original
#define  PLAYBACK_ON_SB
is better.

> Concerning the SB16 driver, I could not record either
> (arecord is blocking indefinitly). Changing the 16 bits DMA control
> did not help.

No, this works. The blocking occurs when some application has an open
file descriptor for playback (in my case, esd for gnome, even in the
state "suspended"). But you must MANUALLY assign  16 bits DMA to
"Playback" to obtain a successful capture (and conversely
assign it to "Capture" for playback). The "Auto" value does not work.
I recall my card is a SB 16 Vibra X PNP, if you want to put a warning
in the README file about that.

Capture for cmi8330: no success at all, with or without
PLAYBACK_ON_SB, and ENABLE_SB_MIXER defined.
But I noticed that I cannot capture (mic recording) with DOS or
Windows either on this machine. The microphone is ok, it is the same
used for the successful SB16 test. So it is not out of possibility there is
a hardware problem on my mainboard (the chip is on it, not on an add-on  
card). I have not currently the possibility to test the "line in" entry. 
I will perhaps test the CD one if it makes sense ?

Regards.

-- 

Bernard Urban


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

Re: CMI8330: success !

[Takashi Iwai]

At 20 Jan 2003 10:43:28 +0100,
Bernard Urban wrote:
> 
> 
> Bernard Urban <Bernard.Urban@meteo.fr> writes:
> > 
> > Notice that I have deleted the controls with false or zero values to
> > save some place. For card0, the SB controls are absent. There are also
> > some differences between controls for card0 and CARD_0, why ? 
> > I get the CARD_0 controls when using alsamixer. 
> > The important thing to notice is that the SB
> > controls need not to be unmuted (as I first believe was necessary) ! 
> > So to have playback it is not needed
> > to define these SB controls in routine cmi8330_add_sb_mixers(). 
> > But the SB initialization step is probably mandatory (I will test it).
> 
> Actually, the cmi8330 card works when undefining ENABLE_SB_MIXER.
> So the init step in snd_sbdsp_create() is sufficient. This is good, as
> you can get rid of these additional and dysfunctional controls.
 
thanks, nice to know that.
does it work w/o ENABLE_SB_MXIER even after rebooting (i mean, after
resetting the hardware) ?


> > 
> > Actually, this is somehow curious, as PLAYBACK_ON_SB is defined, and
> > so playback should go through SB ??? It is apparently not the case.
> > 
> > Only one application did not work correctly, namely the old libc5
> > based xquake (yes, I have done
> > echo "xquake.real 0 0 direct" >/proc/asound/card0/pcm0p/oss).
> > There is sound, but extremely noisy.
> > 
> > Some words about the behaviour of the SB controls in alsamixer:
> > "SB" control follows the "SB Capture" control value.
> > "SB Synth", "SB PCM" and "SB Speaker" do not respond to commands.
> > "SB CD", "SB Line" and "SB Mic" cannot have values above 10%.
> > 
> > I have also tried both "SB Mic" and "Mic" controls in alsamixer, 
> > but capture did not work at all (only noise is registered and I have
> > Larsen effect when the volume is pushed too high). Nevertheless, 
> > as "SB Mic" cannot have values above 10%, here lies perhaps the 
> > problem.
> > 
> > I will now try to use #undefine  PLAYBACK_ON_SB.
> 
> This works also, with ENABLE_SB_MIXER defined, 
> but some .wav files played on events in the desktop
> are scratchy (sometimes, not always). So the original
> #define  PLAYBACK_ON_SB
> is better.

ok.

> > Concerning the SB16 driver, I could not record either
> > (arecord is blocking indefinitly). Changing the 16 bits DMA control
> > did not help.
> 
> No, this works. The blocking occurs when some application has an open
> file descriptor for playback (in my case, esd for gnome, even in the
> state "suspended"). But you must MANUALLY assign  16 bits DMA to
> "Playback" to obtain a successful capture (and conversely
> assign it to "Capture" for playback). The "Auto" value does not work.
> I recall my card is a SB 16 Vibra X PNP, if you want to put a warning
> in the README file about that.

then we can set "playback" as default for Vibra X PnP.

i'm not sure whether it's a general problem for all SB16 Vibra
models, or Vibra X only.   does anyone know that?


> Capture for cmi8330: no success at all, with or without
> PLAYBACK_ON_SB, and ENABLE_SB_MIXER defined.
> But I noticed that I cannot capture (mic recording) with DOS or
> Windows either on this machine. The microphone is ok, it is the same
> used for the successful SB16 test. So it is not out of possibility there is
> a hardware problem on my mainboard (the chip is on it, not on an add-on  
> card). I have not currently the possibility to test the "line in" entry. 
> I will perhaps test the CD one if it makes sense ?

yes, but make sure that you connected the CD-cable :)


ciao,

Takashi


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

Re: CMI8330: success !

[Bernard Urban]

Takashi Iwai <tiwai@suse.de> writes:

[...]

>  
> thanks, nice to know that.
> does it work w/o ENABLE_SB_MXIER even after rebooting (i mean, after
> resetting the hardware) ?

Yes, even after power down/power up (and it is not an ATX power
supply, so it is really down when you switch off).

[...]
> 
> > Capture for cmi8330: no success at all, with or without
> > PLAYBACK_ON_SB, and ENABLE_SB_MIXER defined.
> > But I noticed that I cannot capture (mic recording) with DOS or
> > Windows either on this machine. The microphone is ok, it is the same
> > used for the successful SB16 test. So it is not out of possibility there is
> > a hardware problem on my mainboard (the chip is on it, not on an add-on  
> > card). I have not currently the possibility to test the "line in" entry. 
> > I will perhaps test the CD one if it makes sense ?
> 
> yes, but make sure that you connected the CD-cable :)
> 

Good news, capture works with CD !

Only one gotcha (probably not related to the cmi8330 driver): 
there are "Line Capture Volume", "Mic Capture Volume"
and "CD Capture Volume" controls. The first 2 appear in alsamixer, 
but not the CD one ? 
So you must raise the CD capture volume with amixer.

Sincerely.

-- 

Bernard Urban


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: CMI8330: success !

[Takashi Iwai]

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

Hi,

At 21 Jan 2003 11:11:55 +0100,
Bernard Urban wrote:
> 
> > > Capture for cmi8330: no success at all, with or without
> > > PLAYBACK_ON_SB, and ENABLE_SB_MIXER defined.
> > > But I noticed that I cannot capture (mic recording) with DOS or
> > > Windows either on this machine. The microphone is ok, it is the same
> > > used for the successful SB16 test. So it is not out of possibility there is
> > > a hardware problem on my mainboard (the chip is on it, not on an add-on  
> > > card). I have not currently the possibility to test the "line in" entry. 
> > > I will perhaps test the CD one if it makes sense ?
> > 
> > yes, but make sure that you connected the CD-cable :)
> > 
> 
> Good news, capture works with CD !
> 
> Only one gotcha (probably not related to the cmi8330 driver): 
> there are "Line Capture Volume", "Mic Capture Volume"
> and "CD Capture Volume" controls. The first 2 appear in alsamixer, 
> but not the CD one ? 
> So you must raise the CD capture volume with amixer.

it's a typo in the driver.
please try the attached patch.


Takashi

[-- Attachment #2: cmi-cd-vol-fix.dif --]
[-- Type: application/octet-stream, Size: 1104 bytes --]

Index: alsa-kernel/isa/cmi8330.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/isa/cmi8330.c,v
retrieving revision 1.12
diff -u -r1.12 cmi8330.c
--- alsa-kernel/isa/cmi8330.c	9 Jan 2003 10:45:09 -0000	1.12
+++ alsa-kernel/isa/cmi8330.c	21 Jan 2003 10:14:38 -0000
@@ -59,7 +59,7 @@
 
 /*
  */
-#define ENABLE_SB_MIXER
+/* #define ENABLE_SB_MIXER */
 #define PLAYBACK_ON_SB
 
 /*
@@ -209,7 +209,7 @@
 AD1848_DOUBLE("CD Playback Switch", 0, CMI8330_MUTEMUX, CMI8330_MUTEMUX, 2, 1, 1, 0),
 AD1848_DOUBLE("CD Capture Switch", 0, CMI8330_RMUX3D, CMI8330_RMUX3D, 4, 3, 1, 0),
 AD1848_DOUBLE("CD Playback Volume", 0, CMI8330_CDINVOL, CMI8330_CDINVOL, 4, 0, 15, 0),
-AD1848_DOUBLE("CD Capture Switch", 0, CMI8330_CDINGAIN, CMI8330_CDINGAIN, 4, 0, 15, 0),
+AD1848_DOUBLE("CD Capture Volume", 0, CMI8330_CDINGAIN, CMI8330_CDINGAIN, 4, 0, 15, 0),
 AD1848_SINGLE("Mic Playback Switch", 0, CMI8330_MUTEMUX, 0, 1, 0),
 AD1848_SINGLE("Mic Playback Volume", 0, CMI8330_OUTPUTVOL, 0, 7, 0),
 AD1848_SINGLE("Mic Capture Switch", 0, CMI8330_RMUX3D, 0, 1, 0),

Re: Requested: CMI8330 testers?

[Bernard Urban]

Takashi Iwai <tiwai@suse.de> writes:

[...]

>    echo "xquake 0 0 direct" > /proc/asound/card0/pcm0p/oss
> 
> please check alsa-kernel/Documentation/ALSA-Configuration.txt for
> details.
> 
> 
> > Now the AMD K6-II with a SB Vibra 16X PnP: runs with snd-sb16. In the
> > mixer I must force the 16 bit DMA to be allocated to Capture 
> > to have PCM sound for all kind of audio formats. If set to Auto, for instance
> > .au format is not recognized. Also, xquake runs and  produces sound only with
> > option 8bits sound.
> 
> perhaps this is also related with the above.

Yes, this works ! No more flag for 8 bits sound required.
I missed it the first time, as what you need
actually is:
echo "xquake.real 0 0 direct" > /proc/asound/card0/pcm0p/oss

(xquake is a shell wrapper for the real binary xquake.real)

> > quakeforge works well, but there is a time lag in
> > producing sound, which does not exist with the OSS driver. 
> > Tuning snd-mixahead does not help. 
>  
> this is not sure.  does the delay happen only on quake or do you mean
> it generally?  if it's general behavior, then it's easier to debug.
> anyway we need to trace at which point the delay occurs.

It is not general behaviour, alas. More specifically:
quakeforge with alsa sound output and alsa driver has the time lag
(nearly 0.5 second).
quakeforge with OSS sound output and OSS 'sb' driver works well.
quakeforge with OSS sound output and alsa OSS emulation driver 
works well, using:

echo "nq-glx 0 0 direct" > /proc/asound/card0/pcm0p/oss

but when you quit, the program locks itself (no machine crash, only
the program is blocked, you need to kill it).

Using quake2forge (a quake2 port, without alsa support) under alsa
OSS emulation driver with:

echo "quake2 0 0 direct" > /proc/asound/card0/pcm0p/oss

it works also well, but same program lock when quitting as with quakeforge.
I will try to investigate where it blocks (last message is about DMA
buffer release).

Regards.
 
-- 

Bernard Urban


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: SB 16 driver OSS emulation

[Bernard Urban]

This gives additional details about the blocking with the sb16 driver:

Bernard Urban <Bernard.Urban@meteo.fr> writes:

[...]

> quakeforge with alsa sound output and alsa driver has the time lag
> (nearly 0.5 second).
> quakeforge with OSS sound output and OSS 'sb' driver works well.
> quakeforge with OSS sound output and alsa OSS emulation driver 
> works well, using:
> 
> echo "nq-glx 0 0 direct" > /proc/asound/card0/pcm0p/oss
> 
> but when you quit, the program locks itself (no machine crash, only
> the program is blocked, you need to kill it).
> 
> Using quake2forge (a quake2 port, without alsa support) under alsa
> OSS emulation driver with:
> 
> echo "quake2 0 0 direct" > /proc/asound/card0/pcm0p/oss
> 
> it works also well, but same program lock when quitting as with quakeforge.
> I will try to investigate where it blocks (last message is about DMA
> buffer release).

quake2forge obtains an 'audio_fd' file descriptor by opening
"/dev/dsp". There is a DMA buffer mmaped associated.

At shutdown of the program, the DMA buffer is un-mmaped, and
the following close(audio_fd) blocks. This seems really weird !!! 
A 'close' system call cannot block ???

Actually, doing or not
echo "quake2 0 0 direct" > /proc/asound/card0/pcm0p/oss
makes no difference.

(By Monday, I hope I can send you the results of the CMI8330 patches.)

Regards.

-- 

Bernard Urban


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com