cs64xx distortion (GameTheater XP)

cs64xx distortion (GameTheater XP)

[Christian Esken]

Hi,

I wonder what the status of the cs64xx distortion problem is.
I tested the 2003-01-14.tar.bz2 snapshot with my GameThaeter 7.1 XP
and it still shows those heavy distortions on analog output.

Digital out is OK most of the time, but sometimes fails (as described in cs62xx_lib.c).
I thought you might be interested in the syslog:

PCI: Found IRQ 7 for device 00:0a.0
ALSA ../../alsa-kernel/pci/cs46xx/cs46xx_lib.c:3855: hack for Hercules Game Theatre XP enabled
ALSA ../../alsa-kernel/pci/cs46xx/cs46xx_lib.c:3866: Crystal EAPD support forced on.
ALSA ../alsa-kernel/core/pcm_lib.c:123: Unexpected hw_pointer value (stream = 0, delta: -512, max jitter = 8192): wrong interrupt acknowledge?
ALSA ../alsa-kernel/core/pcm_lib.c:123: Unexpected hw_pointer value (stream = 0, delta: -512, max jitter = 8192): wrong interrupt acknowledge?
ALSA ../alsa-kernel/core/pcm_lib.c:123: Unexpected hw_pointer value (stream = 0, delta: -512, max jitter = 8192): wrong interrupt acknowledge?

I am wondering about the status, as there is still this comment in cs64xx_lib.c:
---------------------------
        /* CD mute change ? */

        /* Benny: this hack dont seems to make any sense to me, at least on the
Game Theater XP,
           Turning of the amplifier just make the PCM sound very distorcionated.           is this really needed ????????????????
        */
---------------------------

And what about CONFIG_SND_CS46XX_NEW_DSP? I left the default, which seems to be
-DCONFIG_SND_CS46XX_NEW_DSP=1
Which means, the "CD mute change" stuff is not compiled in at all.


Bye,
  Chris

being terribly confused at the moment - hoping for enlightenment :)


-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate 
is essential in establishing user confidence by providing assurance of 
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en

Re: cs64xx distortion (GameTheater XP)

[Takashi Iwai]

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

At Thu, 16 Jan 2003 00:14:10 +0100,
Christian Esken wrote:
> 
> Hi,
> 
> I wonder what the status of the cs64xx distortion problem is.
> I tested the 2003-01-14.tar.bz2 snapshot with my GameThaeter 7.1 XP
> and it still shows those heavy distortions on analog output.
> 
> Digital out is OK most of the time, but sometimes fails (as described in cs62xx_lib.c).
> I thought you might be interested in the syslog:
> 
> PCI: Found IRQ 7 for device 00:0a.0
> ALSA ../../alsa-kernel/pci/cs46xx/cs46xx_lib.c:3855: hack for Hercules Game Theatre XP enabled
> ALSA ../../alsa-kernel/pci/cs46xx/cs46xx_lib.c:3866: Crystal EAPD support forced on.
                                
well, it looks like you passed external_amp=1 option to the module,
which you don't need usually.


anyway, try the attached patch (and without external_amp=1 option).
it will clean up the amplifier controls.


Takashi

[-- Attachment #2: cs46xx-amp.dif --]
[-- Type: application/octet-stream, Size: 5833 bytes --]

Index: alsa-kernel/pci/cs46xx/cs46xx_lib.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/cs46xx/cs46xx_lib.c,v
retrieving revision 1.40
diff -u -r1.40 cs46xx_lib.c
--- alsa-kernel/pci/cs46xx/cs46xx_lib.c	7 Jan 2003 10:33:23 -0000	1.40
+++ alsa-kernel/pci/cs46xx/cs46xx_lib.c	16 Jan 2003 10:14:30 -0000
@@ -273,9 +273,6 @@
 				   unsigned short val)
 {
 	cs46xx_t *chip = snd_magic_cast(cs46xx_t, ac97->private_data, return);
-#ifndef CONFIG_SND_CS46XX_NEW_DSP
-	int val2 = 0;
-#endif
 	int codec_index = -1;
 
 	/* UGGLY: nr_ac97_codecs == 0 primery codec detection is in progress */
@@ -287,59 +284,9 @@
 	else
 		snd_assert(0,return);
 
-#ifndef CONFIG_SND_CS46XX_NEW_DSP
-	if (reg == AC97_CD)
-		val2 = snd_cs46xx_codec_read(chip, AC97_CD, codec_index);
-#endif
-
+	chip->active_ctrl(chip, 1);
 	snd_cs46xx_codec_write(chip, reg, val, codec_index);
-
-#ifndef CONFIG_SND_CS46XX_NEW_DSP
-    /* Benny: I've not found *one* soundcard where
-       this code below could do any sense, and
-       with the HW mixering it's anyway broken, with
-       more then 1 PCM stream the amplifier will not
-       be turned off by unmuting CD channel. So just
-       lets skip it.
-    */
-	
-	/*
-	 *	Adjust power if the mixer is selected/deselected according
-	 *	to the CD.
-	 *
-	 *	IF the CD is a valid input source (mixer or direct) AND
-	 *		the CD is not muted THEN power is needed
-	 *
-	 *	We do two things. When record select changes the input to
-	 *	add/remove the CD we adjust the power count if the CD is
-	 *	unmuted.
-	 *
-	 *	When the CD mute changes we adjust the power level if the
-	 *	CD was a valid input.
-	 *
-	 *      We also check for CD volume != 0, as the CD mute isn't
-	 *      normally tweaked from userspace.
-	 */
-	 
-	/* CD mute change ? */
-
-	/* Benny: this hack dont seems to make any sense to me, at least on the Game Theater XP,
-	   Turning of the amplifier just make the PCM sound very distorcionated.
-	   is this really needed ????????????????
-	*/
-	if (reg == AC97_CD) {
-		/* Mute bit change ? */
-		if ((val2^val)&0x8000 || ((val2 == 0x1f1f || val == 0x1f1f) && val2 != val)) {
-			/* Mute on */
-			if(val&0x8000 || val == 0x1f1f)
-				chip->amplifier_ctrl(chip, -1);
-			else /* Mute off power on */
-				chip->amplifier_ctrl(chip, 1);
-		}
-	}
-
 	chip->active_ctrl(chip, -1);
-#endif
 }
 
 
@@ -1506,7 +1453,6 @@
 	if (chip->accept_valid)
 		substream->runtime->hw.info |= SNDRV_PCM_INFO_MMAP_VALID;
 	chip->active_ctrl(chip, 1);
-	chip->amplifier_ctrl(chip, 1);
 
 	return 0;
 }
@@ -1570,7 +1516,6 @@
 		substream->runtime->hw.info |= SNDRV_PCM_INFO_MMAP_VALID;
 
 	chip->active_ctrl(chip, 1);
-	chip->amplifier_ctrl(chip, 1);
 
 #ifdef CONFIG_SND_CS46XX_NEW_DSP
 	snd_pcm_hw_constraint_list(substream->runtime, 0,
@@ -1605,7 +1550,6 @@
 	cpcm->substream = NULL;
 	snd_free_pci_pages(chip->pci, cpcm->hw_size, cpcm->hw_area, cpcm->hw_addr);
 	chip->active_ctrl(chip, -1);
-	chip->amplifier_ctrl(chip, -1);
 
 	return 0;
 }
@@ -1617,7 +1561,6 @@
 	chip->capt.substream = NULL;
 	snd_free_pci_pages(chip->pci, chip->capt.hw_size, chip->capt.hw_area, chip->capt.hw_addr);
 	chip->active_ctrl(chip, -1);
-	chip->amplifier_ctrl(chip, -1);
 
 	return 0;
 }
@@ -3545,9 +3488,6 @@
 {
 	snd_printdd ("initializing Voyetra mixer\n");
 
-	/* turnon Amplifier and leave it on */
-	chip->amplifier_ctrl(chip, 1);
-  
 	/* Enable SPDIF out */
 	snd_cs46xx_pokeBA0(chip, BA0_EGPIODR, EGPIODR_GPOE0);
 	snd_cs46xx_pokeBA0(chip, BA0_EGPIOPTR, EGPIODR_GPOE0);
@@ -3566,9 +3506,6 @@
 	snd_printdd ("initializing Hercules mixer\n");
 
 #ifdef CONFIG_SND_CS46XX_NEW_DSP
-	/* turnon Amplifier and leave it on */
-	chip->amplifier_ctrl(chip, 1);
-
 	for (idx = 0 ; idx < sizeof(snd_hercules_controls) / 
 		     sizeof(snd_hercules_controls[0]) ; idx++) {
 		snd_kcontrol_t *kctl;
@@ -3708,6 +3645,8 @@
 #ifdef CONFIG_PM
 void snd_cs46xx_suspend(cs46xx_t *chip)
 {
+	int amp_saved;
+
 	snd_card_t *card = chip->card;
 
 	if (card->power_state == SNDRV_CTL_POWER_D3hot)
@@ -3715,7 +3654,13 @@
 	snd_pcm_suspend_all(chip->pcm);
 	// chip->ac97_powerdown = snd_cs46xx_codec_read(chip, AC97_POWER_CONTROL);
 	// chip->ac97_general_purpose = snd_cs46xx_codec_read(chip, BA0_AC97_GENERAL_PURPOSE);
+	amp_saved = chip->amplifier;
+	/* turn off amp */
+	chip->amplifier_ctrl(chip, -chip->amplifier);
 	snd_cs46xx_hw_stop(chip);
+	/* disable CLKRUN */
+	chip->active_ctrl(chip, -chip->amplifier);
+	chip->amplifier = amp_saved; /* restore the status */
 	snd_power_change_state(card, SNDRV_CTL_POWER_D3hot);
 }
 
@@ -3748,11 +3693,10 @@
 	snd_ac97_resume(chip->ac97[CS46XX_PRIMARY_CODEC_INDEX]);
 
 	if (amp_saved)
-		chip->amplifier_ctrl(chip, 1); /* try to turn on */
-	if (! amp_saved) {
-		chip->amplifier = 1;
-		chip->active_ctrl(chip, -1);
-	}
+		chip->amplifier_ctrl(chip, 1); /* turn amp on */
+	else
+		chip->active_ctrl(chip, -1); /* disable CLKRUN */
+	chip->amplifier = amp_saved;
 	snd_power_change_state(card, SNDRV_CTL_POWER_D0);
 }
 
@@ -3853,11 +3797,11 @@
 	for (cp = &cards[0]; cp->name; cp++) {
 		if (cp->vendor == ss_vendor && cp->id == ss_card) {
 			snd_printd ("hack for %s enabled\n", cp->name);
-			if (cp->init)
-				cp->init(chip);
 			chip->amplifier_ctrl = cp->amp;
 			chip->active_ctrl = cp->active;
 			chip->mixer_init = cp->mixer_init;
+			if (cp->init)
+				cp->init(chip);
 			break;
 		}
 	}
@@ -3878,7 +3822,7 @@
 	if (chip->active_ctrl == NULL)
 		chip->active_ctrl = amp_none;
 
-	chip->active_ctrl(chip, 1);
+	chip->active_ctrl(chip, 1); /* enable CLKRUN */
 
 	pci_set_master(pci);
 
@@ -3929,7 +3873,10 @@
 		return err;
 	}
 	
-	chip->active_ctrl(chip, -1);
+	/* turn on amplifier */
+	chip->amplifier_ctrl(chip, 1);
+
+	chip->active_ctrl(chip, -1); /* disable CLKRUN */
 
 	*rchip = chip;
 	return 0;

Re: cs64xx distortion (GameTheater XP)

[Benny Sjostrand]

>
>
>I wonder what the status of the cs64xx distortion problem is.
>I tested the 2003-01-14.tar.bz2 snapshot with my GameThaeter 7.1 XP
>
My opinion: the GameTheater XP it's a cheap soundcard with a beautiful 
blue box. Usually cheap soundcard got a cheap design as result of a tiny 
bugdet, so just dont expect to much from the analog part's.

Actually I got a Hercules GameTheater XP 6.1, when volume is over about 
a ~80% the output is sometimes distorcionated, but I believe that's 
something we cant do anything about in the driver. Limit some volume 
control's in the driver dont feel like a coherent solution.

The card is still usable, I really dont expect to better quality on 
analog output with this soundcard.

>ALSA ../alsa-kernel/core/pcm_lib.c:123: Unexpected hw_pointer value (stream = 0, delta: -512, max jitter = 8192): wrong interrupt acknowledge?
>ALSA ../alsa-kernel/core/pcm_lib.c:123: Unexpected hw_pointer value (stream = 0, delta: -512, max jitter = 8192): wrong interrupt acknowledge?
>ALSA ../alsa-kernel/core/pcm_lib.c:123: Unexpected hw_pointer value (stream = 0, delta: -512, max jitter = 8192): wrong interrupt acknowledge?
>  
>
Feel like theese messages should not be there, could be a bug in cs46xx 
driver.

>I am wondering about the status, as there is still this comment in cs64xx_lib.c:
>---------------------------
>        /* CD mute change ? */
>
>        /* Benny: this hack dont seems to make any sense to me, at least on the
>Game Theater XP,
>           Turning of the amplifier just make the PCM sound very distorcionated.           is this really needed ????????????????
>        */
>---------------------------
>
>  
>
Should only matter if you unmute the analog CD input, and with the new 
DSP code it dont matter at all.

/Benny



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

FIX: soundblaster rear channels (ens1371)

[Pieter Palmers]

Finally I figured out how to enable the rear channel separately from the front 
on the creative labs CT5880 (= modified ens1371 as it seems).

I'll describe the settings to enable this, but I'm not going to submit a 
patch, as I have noticed that I messed up my ens1370.c too much, and I can't 
get a clean version because CVS doesn't work. It's a minor change, so I 
assume it can be done by the maintainers.

The whole thing is in three bits in the BASE+0x04 register (ES_REG_STATUS in 
the driver). These bits are bit27, bit26 and bit24
There are three modes of operation:
1) No rear output: bit27=bit26=bit24=0
2) rear output is a mirror of the main output, but controlled by the 
'surround' slider of the mixer. I assume the ens1371 mixes the two 'devices' 
and sends the mix to both MAIN and SURROUND DAC. This mode is selected by 
setting  bit27=bit24=0 and bit26=1
3) independant rear (surround) and front output. Using the current driver, 
this has the strange side-effect that HW:0,0 becomes the rear output and 
HW:0,1 becomes the front. So HW:0,0 is controlled by the 'surround' mixer 
control, and HW:1,0 is controlled by the PCM and Master mixer controls. To 
select this mode set bit27=bit24=1 and bit26=0. It seems that bit27=1 and 
bit24=bit26=0 is identical, but the windows driver clearly does the first, so 
why not? It works...

front only, no rear: 		bit27=0	bit26=0	bit24=0
rear mirrors front:		bit27=0 	bit26=1 	bit24=0
front & rear independant:	bit27=1 	bit26=0 	bit24=1 (x?)


I patched my driver by inserting the following code around line 1947:
(I included two lines of overlap to make the location easier to find)
=============================================
	outb(ensoniq->uartc = 0x00, ES_REG(ensoniq, UART_CONTROL)); 
	outb(0x00, ES_REG(ensoniq, UART_RES));

#ifdef CHIP1371
	/* enable the rear outputs
	This seems to work
	ensoniq->cssr |= (0 << 27) | (1 << 24);
	but the windows driver does this, so let's
	also do it */

	ensoniq->cssr |= (1 << 27) | (1 << 24);

	/*
	Use this for mirror mode
	ensoniq->cssr |= (1 << 26);*/
#endif

	outl(ensoniq->cssr, ES_REG(ensoniq, STATUS));
#if defined(CONFIG_GAMEPORT) || defined(CONFIG_GAMEPORT_MODULE)
=============================================

Maybe there is a better place to put this? I don't know... I put it in the 
snd_ensoniq_create() function because I always want 4ch output, and I don't 
see the use of the other modes in an ALSA enviroment.

Regards,

Pieter

PS: I'm also developing a driver for my Maxisound ISIS, where do I look for 
information on ALSA/linux driver developement? Does anyone have a 'template' 
ALSA driver?
Does ALSA support non-DMA audio transfer? I believe the ISIS uses this kind of 
transfers, but I don't know for sure yet. I know it's stupid design not to 
use DMA, but there is nothing to do about it I guess.



-------------------------------------------------------
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: cs64xx distortion (GameTheater XP)

[Richard Olsson]

Benny Sjostrand <gorm@cucumelo.org> wrote:
> My opinion: the GameTheater XP it's a cheap soundcard with a beautiful
> blue box. Usually cheap soundcard got a cheap design as result of a
> tiny bugdet, so just dont expect to much from the analog part's.

Constantly saying that it's a cheap soundcard isn't really a solution
though.  While it might not be a card suited for an audiophile it's
certainly better than several other cards out there.  And the Windows
drivers don't have any problems like this. ;)

My GTXP works well enough though, though sound does get disorted/etc
when using more than ~80% volume as well.  I hardly see that as a
problem though.

-- 
Richard Olsson
E: flame@home.se
W: http://www.nyo-box.net/


-------------------------------------------------------
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: FIX: soundblaster rear channels (ens1371)

[Takashi Iwai]

At Fri, 17 Jan 2003 01:04:40 +0100,
Pieter Palmers wrote:
> 
> Finally I figured out how to enable the rear channel separately from the front 
> on the creative labs CT5880 (= modified ens1371 as it seems).
 
great!  thanks for your work!

> I'll describe the settings to enable this, but I'm not going to submit a 
> patch, as I have noticed that I messed up my ens1370.c too much, and I can't 
> get a clean version because CVS doesn't work. It's a minor change, so I 
> assume it can be done by the maintainers.
> 
> The whole thing is in three bits in the BASE+0x04 register (ES_REG_STATUS in 
> the driver). These bits are bit27, bit26 and bit24
> There are three modes of operation:
> 1) No rear output: bit27=bit26=bit24=0
> 2) rear output is a mirror of the main output, but controlled by the 
> 'surround' slider of the mixer. I assume the ens1371 mixes the two 'devices' 
> and sends the mix to both MAIN and SURROUND DAC. This mode is selected by 
> setting  bit27=bit24=0 and bit26=1
> 3) independant rear (surround) and front output. Using the current driver, 
> this has the strange side-effect that HW:0,0 becomes the rear output and 
> HW:0,1 becomes the front. So HW:0,0 is controlled by the 'surround' mixer 
> control, and HW:1,0 is controlled by the PCM and Master mixer
> controls.

this is because we are using DAC2 for the hw:0,0 and DAC1 for hw:0,1.
i'm not sure why it is.

Jaroslav, is there any drawback to use DAC1 as default playback?
(i know that the OSS driver uses this order, too.)


> To 
> select this mode set bit27=bit24=1 and bit26=0. It seems that bit27=1 and 
> bit24=bit26=0 is identical, but the windows driver clearly does the first, so 
> why not? It works...
> 
> front only, no rear: 		bit27=0	bit26=0	bit24=0
> rear mirrors front:		bit27=0 	bit26=1 	bit24=0
> front & rear independant:	bit27=1 	bit26=0 	bit24=1 (x?)
> 
> 
> I patched my driver by inserting the following code around line 1947:
> (I included two lines of overlap to make the location easier to find)
> =============================================
> 	outb(ensoniq->uartc = 0x00, ES_REG(ensoniq, UART_CONTROL)); 
> 	outb(0x00, ES_REG(ensoniq, UART_RES));
> 
> #ifdef CHIP1371
> 	/* enable the rear outputs
> 	This seems to work
> 	ensoniq->cssr |= (0 << 27) | (1 << 24);
> 	but the windows driver does this, so let's
> 	also do it */
> 
> 	ensoniq->cssr |= (1 << 27) | (1 << 24);
> 
> 	/*
> 	Use this for mirror mode
> 	ensoniq->cssr |= (1 << 26);*/
> #endif
> 
> 	outl(ensoniq->cssr, ES_REG(ensoniq, STATUS));
> #if defined(CONFIG_GAMEPORT) || defined(CONFIG_GAMEPORT_MODULE)
> =============================================
> 
> Maybe there is a better place to put this? I don't know... I put it in the 
> snd_ensoniq_create() function because I always want 4ch output, and I don't 
> see the use of the other modes in an ALSA enviroment.
 
it would be better to create new controls, and changing the controls
via hook in the pcm configuration.


> Regards,
> 
> Pieter
> 
> PS: I'm also developing a driver for my Maxisound ISIS, where do I look for 
> information on ALSA/linux driver developement? Does anyone have a 'template' 
> ALSA driver?

there is a tutorial,
	http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html

the docbook source is found in alsa-kernel/Documentation/DocBook.


> Does ALSA support non-DMA audio transfer? I believe the ISIS uses this kind of 
> transfers, but I don't know for sure yet. I know it's stupid design not to 
> use DMA, but there is nothing to do about it I guess.

yes, but the implementation depends on the driver.
you can use tasklet for transferring the data e.g. via io-port
read/write.

Uros has been working on the ALSA SAM9407 driver, and IIRC, maxi ISIS
uses a similar (same?) chip.  he might be able to help the development
of this driver.


ciao,

Takashi


-------------------------------------------------------
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: FIX: soundblaster rear channels (ens1371)

[Pieter Palmers]

>> 
>> Finally I figured out how to enable the rear channel separately from the 
front 
>> on the creative labs CT5880 (= modified ens1371 as it seems).
 
>great!  thanks for your work!

no problem. 
Thank you guys for your work. Figuring this out took me half a day. I'm sure 
that you guys all spent more than that on this project. I'm happy to be able 
to help out. I wanted the rear channels to work, and so I tried it myself. 
Now everybody can benifit from this work. Isn't this the way open-source 
works? take a lot - give what you can

> Uros has been working on the ALSA SAM9407 driver, and IIRC, maxi ISIS
> uses a similar (same?) chip.  he might be able to help the development
> of this driver.
>
The ISIS uses the successor of the SAM9407, the SAM9707. Differences seem to 
be minor (only the fact that it supports 6 extra channels).

The problem is that it is an ISA chip, and they used a 'creative' way of 
building a PCI card with it: They built a card based on the ESS Maestro-2EM, 
which is an Maestro-2E with an additional 'modem dsp' port, i.e. an ISA port. 
They used this port to connect the SAM chip.

So actually it would be helpfull if I had someone with ESS Maestro experience. 
I'm wondering if it's possible to set up a DMA transfer to the modem port. 
The Maestro is (in my opinion) a pretty compicated device so I think it might 
be possible.
Any Maestro-connaiseurs on this list?

Pieter




-------------------------------------------------------
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: FIX: soundblaster rear channels (ens1371)

[Takashi Iwai]

At Fri, 17 Jan 2003 11:23:42 +0100,
Pieter Palmers wrote:
> 
> > Uros has been working on the ALSA SAM9407 driver, and IIRC, maxi ISIS
> > uses a similar (same?) chip.  he might be able to help the development
> > of this driver.
> >
> The ISIS uses the successor of the SAM9407, the SAM9707. Differences seem to 
> be minor (only the fact that it supports 6 extra channels).
> 
> The problem is that it is an ISA chip, and they used a 'creative' way of 
> building a PCI card with it: They built a card based on the ESS Maestro-2EM, 
> which is an Maestro-2E with an additional 'modem dsp' port, i.e. an ISA port. 
> They used this port to connect the SAM chip.
> 
> So actually it would be helpfull if I had someone with ESS Maestro experience. 
> I'm wondering if it's possible to set up a DMA transfer to the modem port. 
> The Maestro is (in my opinion) a pretty compicated device so I think it might 
> be possible.
> Any Maestro-connaiseurs on this list?

well, i'm the maintainer of es1968 driver, but the driver is atm not
well maintained.  the chip is yes a bit complicated but the problem is
lack of proper documents.  there is a data sheet but it doesn't
describe any essential parts.  and we have only a crappy buggy DOS
example code...

anyway, please let me know if you have any questions.


ciao,

Takashi


-------------------------------------------------------
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: FIX: soundblaster rear channels (ens1371)

[Jaroslav Kysela]

On Fri, 17 Jan 2003, Takashi Iwai wrote:

> this is because we are using DAC2 for the hw:0,0 and DAC1 for hw:0,1.
> i'm not sure why it is.
> 
> Jaroslav, is there any drawback to use DAC1 as default playback?
> (i know that the OSS driver uses this order, too.)

This switch was for ENS1370 chip which has DAC0 rates a bit restricted. 
I've reversed streams for ENS1371.

> > To 
> > select this mode set bit27=bit24=1 and bit26=0. It seems that bit27=1 and 
> > bit24=bit26=0 is identical, but the windows driver clearly does the first, so 
> > why not? It works...
> > 
> > front only, no rear: 		bit27=0	bit26=0	bit24=0
> > rear mirrors front:		bit27=0 	bit26=1 	bit24=0
> > front & rear independant:	bit27=1 	bit26=0 	bit24=1 (x?)
> > 
> > 
> > I patched my driver by inserting the following code around line 1947:
> > (I included two lines of overlap to make the location easier to find)
> > =============================================
> > 	outb(ensoniq->uartc = 0x00, ES_REG(ensoniq, UART_CONTROL)); 
> > 	outb(0x00, ES_REG(ensoniq, UART_RES));
> > 
> > #ifdef CHIP1371
> > 	/* enable the rear outputs
> > 	This seems to work
> > 	ensoniq->cssr |= (0 << 27) | (1 << 24);
> > 	but the windows driver does this, so let's
> > 	also do it */
> > 
> > 	ensoniq->cssr |= (1 << 27) | (1 << 24);
> > 
> > 	/*
> > 	Use this for mirror mode
> > 	ensoniq->cssr |= (1 << 26);*/
> > #endif
> > 
> > 	outl(ensoniq->cssr, ES_REG(ensoniq, STATUS));
> > #if defined(CONFIG_GAMEPORT) || defined(CONFIG_GAMEPORT_MODULE)
> > =============================================
> > 
> > Maybe there is a better place to put this? I don't know... I put it in the 
> > snd_ensoniq_create() function because I always want 4ch output, and I don't 
> > see the use of the other modes in an ALSA enviroment.
>  
> it would be better to create new controls, and changing the controls
> via hook in the pcm configuration.

Done. Pieter, can you try the latest CVS source. When surround DAC is 
found, there should be 'AC97 2ch->4ch Copy Switch' which controls 
mirroring / separating channels. The front only configuration will be 
used only for cards with no surround DAC. Thank you for your work.

Please, update also alsa-lib and test these commands:

aplay -Drear <some.wav>
aplay -Dplug:surround40 <some.wav>

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
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: FIX: soundblaster rear channels (ens1371)

[Uros Bizjak]

Takashi Iwai wrote:

>>Does ALSA support non-DMA audio transfer? I believe the ISIS uses this kind of 
>>transfers, but I don't know for sure yet. I know it's stupid design not to 
>>use DMA, but there is nothing to do about it I guess.
>>    
>>
>
>yes, but the implementation depends on the driver.
>you can use tasklet for transferring the data e.g. via io-port
>read/write.
>
>Uros has been working on the ALSA SAM9407 driver, and IIRC, maxi ISIS
>uses a similar (same?) chip.  he might be able to help the development
>of this driver.
>
  Yes, I have working code to communicate with SAM9407 chip (microcode 
loading,
memory management, channel allocation, control interface, etc) and I 
have just start
working on PCM interface.  Unfortunatelly, I haven't got any time to 
implement
PCM routines, but all the low-level routines are in place. The code is 
written for older
0.9.x version of ALSA (as I didn't yet port it to latest CVS).

  If anybody is interested in helping with this project, I would gladly 
share my (partially
functional) code. Code is tested with EWS64XL (PnP detection of SAM9407, 
i2c stuff
and TEA chips are working OK), has many comments, and basically just 
waits for someone to
"fill in the blanks" on PCM part.

  Regarding sam9407: When you set up PCM channel and start transfer, 
chip will signal to driver,
when it is ready to receive data. Following this signal, you send data 
block with outsw()/insw()
command and terminate transfer with chip-specific message sent to 
SAM9407 control port. Some
kind of pseudo DMA.

    Uros.



-------------------------------------------------------
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: FIX: soundblaster rear channels (ens1371)

[Takashi Iwai]

At Fri, 17 Jan 2003 13:11:12 +0100,
Pieter Palmers wrote:
> 
> >
> > Done. Pieter, can you try the latest CVS source. When surround DAC is
> > found, there should be 'AC97 2ch->4ch Copy Switch' which controls
> > mirroring / separating channels. The front only configuration will be
> > used only for cards with no surround DAC. Thank you for your work.
> >
> 
> CVS refuses connection:
> 
> 	[ppalmers@ox ppalmers]$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/alsa login
> 	Logging in to :pserver:anonymous@cvs.sourceforge.net:2401/cvsroot/alsa
> 	CVS password:
> 	cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused

yes, the problem seems on the sf site.
please try cvs snapshot available on the alsa ftp.


Takashi


-------------------------------------------------------
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: FIX: soundblaster rear channels (ens1371)

[Pieter Palmers]

>
> Done. Pieter, can you try the latest CVS source. When surround DAC is
> found, there should be 'AC97 2ch->4ch Copy Switch' which controls
> mirroring / separating channels. The front only configuration will be
> used only for cards with no surround DAC. Thank you for your work.
>

CVS refuses connection:

	[ppalmers@ox ppalmers]$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/alsa login
	Logging in to :pserver:anonymous@cvs.sourceforge.net:2401/cvsroot/alsa
	CVS password:
	cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused

	[ppalmers@ox ppalmers]$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/alsa co alsa-driver
	cvs [checkout aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused

Web based access also refuses service:

	An error occured while loading http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/alsa:

	Timeout on server
	cvs.sourceforge.net

Pieter


-------------------------------------------------------
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: FIX: soundblaster rear channels (ens1371)

[Pieter Palmers]

>
> yes, the problem seems on the sf site.
> please try cvs snapshot available on the alsa ftp.
>

snapshots on the ftp site are of size 0Mb since 15-1-2003.



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

support for SAM940x based cards

[Pieter Palmers]

>   Yes, I have working code to communicate with SAM9407 chip (microcode
> loading,
> memory management, channel allocation, control interface, etc) and I
> have just start
> working on PCM interface.  Unfortunatelly, I haven't got any time to
> implement
> PCM routines, but all the low-level routines are in place. The code is
> written for older
> 0.9.x version of ALSA (as I didn't yet port it to latest CVS).
>
>   If anybody is interested in helping with this project, I would gladly
> share my (partially
> functional) code. Code is tested with EWS64XL (PnP detection of SAM9407,
> i2c stuff
> and TEA chips are working OK), has many comments, and basically just
> waits for someone to
> "fill in the blanks" on PCM part.
>

I would surely be interested in this code. I think a lot of code can be shared 
between the cards. The transfer mechanism of the ISIS different, but I think 
it can fit into a general approach i.e. a generic driver for the SAM970x chip 
supported by an 'architecture dependant' driver. 
The isis uses the maestro as a PCI to ISA bride and transfers from/to the chip 
should be done like this: 
(disassembled source at http:/isisalsa.sourceforge.net/assembler.htm)

registers involved:
MAESTRO_BASE + 44h: address of the ISA port (IDMA in ESS terminology) on the 
maestro.
MAESTRO_BASE + 46h: data register for the ISA port

so basically transfers come down to this: (disassembled from win drivers)
	mov ax, 1 		; address 0x01 is the SAM control port
	mov dx, MAESTRO_BASE
	add dx, 44h
	out dx, ax              ; select control port
	mov dx, MAESTRO_BASE
	add dx, 46h 	 ; switch to data register
	in ax, dx               ; read value

	by the way: does anyone know why they don't do it like this:
		mov ax, 1 		; address 0x01 is the SAM control port
		mov dx, MAESTRO_BASE
		add dx, 44h
		out dx, ax              ; select control port
		add dx, 02h 	 ; switch to data register
		in ax, dx               ; read value
	compiler issue?

	to illustrate this even further, consider this piece of code also 
disassembled from the win driver:
	looppoint1:           
       		mov     dx, 1
	        push    dx
 	       	mov     ax, dx
  	      	mov     dx, MAESTRO_BASE
   	     	add     dx, 44h                 ; Add
    		out     dx, ax                  ; control port
	        mov     dx, MAESTRO_BASE
	        add     dx, 46h                 ; Add
	        in      ax, dx                  ; read port
	        and     ax, 0FFh                ; keep lower 8 bits
*	        push    ax
*	        mov     ax, 2
*	        mov     dx, MAESTRO_BASE
*	        add     dx, 44h         ; Add
*	        out     dx, ax                  ; DATA16 port
*	        pop     ax
	        pop     dx
	        test    al, 80h                 ; is TE=0 ?
	        jz      short read_word         ; TE = 1 => data present
	        loop    looppoint1              ; Loop while CX != 0

	I marked the strange part of the code with an asterix. Isn't this pure 
overhead?

that aside, let's get back to the main issue...
The actual PCM data transfer is done with a 'repsw outw' command as sayd by 
Uros. Something like:
       		mov     dx, 2
  	      	mov     dx, MAESTRO_BASE
   	     	add     dx, 44h                 ; Add
    		out     dx, ax                  ; DATA16 port
	        mov     dx, MAESTRO_BASE
	        add     dx, 46h                 ; Add
		repsw outw ... (forgot syntax)

I wondered if it isn't possible to use the Maestro DMA capability to transfer 
the large chunks from main memory to the ISA/IDMA port independant from CPU? 
Do we have any information on this 'DSP modem' or IDMA port on the Maestro 
family? (I assume that ESS hasn't changed that much between Maestro 
generations)


Pieter

PS: I have the sourcecode of the Hoontech ST128 windows drivers (both 9x and 
WDM). If you want them, you can download them at 
http://isisalsa.sourceforge.net. These cards are based on SAM940x chips.

PPS: What do you think of the statement that this type of transfer isn't 
supported in WinXP/NT due to the HAL that OS uses? This is the justification 
of Guillemot not to provide WinXP drivers.



-------------------------------------------------------
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: support for SAM940x based cards

[Uros Bizjak]

Pieter Palmers wrote:

>>  Yes, I have working code to communicate with SAM9407 chip (microcode
>>loading,
>>memory management, channel allocation, control interface, etc) and I
>>have just start
>>working on PCM interface.  Unfortunatelly, I haven't got any time to
>>implement
>>PCM routines, but all the low-level routines are in place. The code is
>>written for older
>>0.9.x version of ALSA (as I didn't yet port it to latest CVS).
>>
>>  If anybody is interested in helping with this project, I would gladly
>>share my (partially
>>functional) code. Code is tested with EWS64XL (PnP detection of SAM9407,
>>i2c stuff
>>and TEA chips are working OK), has many comments, and basically just
>>waits for someone to
>>"fill in the blanks" on PCM part.
>>
>>    
>>
>
>I would surely be interested in this code. I think a lot of code can be shared 
>between the cards. The transfer mechanism of the ISIS different, but I think 
>it can fit into a general approach i.e. a generic driver for the SAM970x chip 
>supported by an 'architecture dependant' driver. 
>
  I have prepared a snapshot of my sam9407 directory at 
www2.arnes.si/~krklubsls1/sam9407-19.Dec.2002-NW.tar.gz
This code has been in working state a couple of months ago, but now it 
is broken because of not-yet-finished PCM changes.

  BTW: I have uploaded some documents found on various sites regarding 
sam9407 programming:
www2.arnes.si/~krklubsls1/TTFirm.ps
www2.arnes.si/~krklubsls1/progref.ps

  And, there are linux drivers (OSS)  - also for ISIS - on  
http://www.anime.net/~sam9407/

    Uros.




-------------------------------------------------------
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: FIX: soundblaster rear channels (ens1371)

[Jaroslav Kysela]

On Fri, 17 Jan 2003, Pieter Palmers wrote:

> 
> >
> > Done. Pieter, can you try the latest CVS source. When surround DAC is
> > found, there should be 'AC97 2ch->4ch Copy Switch' which controls
> > mirroring / separating channels. The front only configuration will be
> > used only for cards with no surround DAC. Thank you for your work.
> >
> 
> CVS refuses connection:
> 
> 	[ppalmers@ox ppalmers]$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/alsa login
> 	Logging in to :pserver:anonymous@cvs.sourceforge.net:2401/cvsroot/alsa
> 	CVS password:
> 	cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused
> 
> 	[ppalmers@ox ppalmers]$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/alsa co alsa-driver
> 	cvs [checkout aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused
> 
> Web based access also refuses service:
> 
> 	An error occured while loading http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/alsa:
> 
> 	Timeout on server
> 	cvs.sourceforge.net

Everything works from here...

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
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: FIX: soundblaster rear channels (ens1371)

[Takashi Iwai]

At Fri, 17 Jan 2003 15:08:45 +0100 (CET),
Jaroslav Kysela wrote:
> 
> On Fri, 17 Jan 2003, Pieter Palmers wrote:
> 
> > 
> > >
> > > Done. Pieter, can you try the latest CVS source. When surround DAC is
> > > found, there should be 'AC97 2ch->4ch Copy Switch' which controls
> > > mirroring / separating channels. The front only configuration will be
> > > used only for cards with no surround DAC. Thank you for your work.
> > >
> > 
> > CVS refuses connection:
> > 
> > 	[ppalmers@ox ppalmers]$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/alsa login
> > 	Logging in to :pserver:anonymous@cvs.sourceforge.net:2401/cvsroot/alsa
> > 	CVS password:
> > 	cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused
> > 
> > 	[ppalmers@ox ppalmers]$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/alsa co alsa-driver
> > 	cvs [checkout aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused
> > 
> > Web based access also refuses service:
> > 
> > 	An error occured while loading http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/alsa:
> > 
> > 	Timeout on server
> > 	cvs.sourceforge.net
> 
> Everything works from here...

yeah, it works again!


Takashi


-------------------------------------------------------
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: cs64xx distortion (GameTheater XP)

[Christian Esken]

Am Friday 17 January 2003 00:11 schrieb Benny Sjostrand:
> >I wonder what the status of the cs64xx distortion problem is.
> >I tested the 2003-01-14.tar.bz2 snapshot with my GameThaeter 7.1 XP
>
> My opinion: the GameTheater XP it's a cheap soundcard with a beautiful
> blue box. Usually cheap soundcard got a cheap design as result of a tiny
> bugdet, so just dont expect to much from the analog part's.

I don't buy this opinion! Measurements published in sound card tests show
a pretty good sound quality.

But apart from that: The sound quality in Linux has NOTHING to do with
the capabilities of the card (as it has no problems under Windwos):
- Sound quality of the card: good (or fair or whatever you like)
- Sound quality under Linux: very very very very bad.

> Actually I got a Hercules GameTheater XP 6.1, when volume is over about
> a ~80% the output is sometimes distorcionated, but I believe that's
> something we cant do anything about in the driver. Limit some volume
> control's in the driver dont feel like a coherent solution.
>
> The card is still usable, I really dont expect to better quality on
> analog output with this soundcard.

Alas - my GameTheater XP 7.1 is not (except digital output).

So if this problem is a known issue, sholdn't there be a hint in the
Alsa Sound Card Matrix. I don't blame anybody (except perhaps
CS), but I think others should be warned on possible problems.

Chris




-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en

Re: cs64xx distortion (GameTheater XP)

[Benny Sjostrand]

>
>
>I don't buy this opinion! Measurements published in sound card tests show
>a pretty good sound quality.
>  
>
Thoose review usually compares the Hercules GTXP with the Sounblaster 
Audigy with breakout box. But about personal soundcard opinions is 
something I think we should discuss outside this mailinglist ...

>But apart from that: The sound quality in Linux has NOTHING to do with
>the capabilities of the card (as it has no problems under Windwos):
>- Sound quality of the card: good (or fair or whatever you like)
>
We dont't known what kind of dirty is hack's possibly could be 
implemented  in the Windows driver to compensate the bad sound. We know 
that the DSP is able to do much more that actually is done in the Linux 
driver, reverb effects, delay, band pass filters, mp3 decoding etc. For 
example what about having a light reverb effect on front speakers, and a 
little bit more reverb on rear speakers + some delay, and let's limit 
the volume controls a little bit to get rid of the a possible 
distorcion, and some few band pass filters. Do you think that would 
improve the sound quality ?

What actually Hercules sells is more SW than HW, there is about three 
version of the Hercules GTXP 5.1, 6.1, 7.1 The the only difference 
between theese cards seems to be the delivered SW (which you probably 
never will use under Linux)

I dont discard posibility that there's something specific about the GTXP 
hw, that we dont know and we should know that could improve sound, but I 
believe that this posibilty is very small.

>- Sound quality under Linux: very very very very bad.
>  
>
It's possible to get good sound quality under Linux with the GTXP, if 
you use an external amplifier, some options that I can mention:
- External receiver with digital in, using the SPDIF output
- External receiver using the analog inputs, using the un-amplified 
outputs from the GTXP
­ - Use any kind of active speakers (speakers with it's own amplifier 
built-in)

Just dont rely to much  on the soundcard amplifier.

>So if this problem is a known issue, sholdn't there be a hint in the
>Alsa Sound Card Matrix. I don't blame anybody (except perhaps
>CS), but I think others should be warned on possible problems.
>
>  
>
If we think that this is a problem in the driver that can be fixed in 
the driver.

/Benny



-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en

Re: cs64xx distortion (GameTheater XP)

[Friedrich Ewaldt]

Benny Sjostrand wrote:

> We dont't known what kind of dirty is hack's possibly could be 
> implemented  in the Windows driver to compensate the bad sound. We 
> know that the DSP is able to do much more that actually is done in the 
> Linux driver, reverb effects, delay, band pass filters, mp3 decoding 
> etc. For example what about having a light reverb effect on front 
> speakers, and a little bit more reverb on rear speakers + some delay, 
> and let's limit the volume controls a little bit to get rid of the a 
> possible distorcion, and some few band pass filters. Do you think that 
> would improve the sound quality ?
>
> What actually Hercules sells is more SW than HW, there is about three 
> version of the Hercules GTXP 5.1, 6.1, 7.1 The the only difference 
> between theese cards seems to be the delivered SW (which you probably 
> never will use under Linux)
>
> I dont discard posibility that there's something specific about the 
> GTXP hw, that we dont know and we should know that could improve 
> sound, but I believe that this posibilty is very small.

I didn't hear this 'bad' sound quality of the GTXP because I've a cs46xx 
based terratec DMX XFire. The sound quality of the XFire is exactly the 
same as under windows, i.e. much better than a cheap $10 soundcard. 
There's not much hardware on the XFire: Basically just the CS4624, a 
CS4294 codec and two LM386 amplifiers (very cheap 1 watt amps). The 
windows driver of the XFire doesn't change the sound in any way like 
adding reverberation, stereo expanding or equalizing (It does only, if 
you tell it to do), i.e. the card acts as a transparent system that just 
outputs every sample like it was told by any application. I think that 
will be also the case for the GTXP under windows (but I can't check as I 
don't own this card). There seem to be other hardware components on the 
GTXP wich are not correctly initialized.

>
>> - Sound quality under Linux: very very very very bad.
>>  
>>
> It's possible to get good sound quality under Linux with the GTXP, if 
> you use an external amplifier, some options that I can mention:
> - External receiver with digital in, using the SPDIF output
> - External receiver using the analog inputs, using the un-amplified 
> outputs from the GTXP
> ­ - Use any kind of active speakers (speakers with it's own amplifier 
> built-in)
>
> Just dont rely to much  on the soundcard amplifier.

If the GTXP is used in the same way as under windows (e.g. line output 
connected to external amp or active speakers), the sound quality should 
be more or less the same.
As Christian says the sound quality is very ve...ry bad, I think it must 
be related with card initialization (something like the DC offset 
problem with the XFire or a not powered up amplifier).

I do not think that the driver has to do some equalization to get good 
quality. The hardware on this card should deliver good quality without 
software tricks. (Of course correct initialization is necessary which 
could perhaps easily done *with some more help provided by this "Cirrus" 
company*).

Chrisian, perhaps you can specify/describe the type of distortion more 
precisely so that it's easier to guess the reason for the bad sound.
Does it sound like overload?
Is the output unequalized, i.e. lack of low or high frequency components.
Are quiet sounds also/more/less distorted? Especially: Are sounds below 
a volume threshold not ouput, quite sounds totally muted?
You reported that lowering pcm/master volume makes the quality somewhat 
better. What about playing back quiet sounds with pcm/master volume 
turned up compared to playing back loud sounds with pcm/master volume 
turned down?
Do you get different quality depending on the analog output used (line 
out with external amp compered to speaker output)?
I don't know about the possibility of the GTXP to power down the 
internal amps. If the sound at line output is ok, that could be the 
reason for the bad quality.




-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your 
clients even if they use browsers that are limited to 40 bit encryption. 
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en