[PATCH] cs46xx some few corrections

[PATCH] cs46xx some few corrections

[Benny Sjostrand]

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

Hi!

If the SPDIF input worked with rc6 it should work now with this patch, 
the SPDIF input "Source Rate Converter"-SCB
was muted all the time and that should fixed by now.
I discovered that AC3 almost works but get very easily out of sync in 
some how (got no solution for this yet)
Restarting the application about ~ 10 times, eg. with xine press 
PLAY-STOP PLAY-STOP ... until you get
sound.
There was/is actually a ring buffer problem in the cs46xx driver giving 
this kind of outputs (see my previous mail):
"Dec 8 13:40:16 cactus kernel: ALSA ../alsa-kernel/core/pcm_lib.c:176: 
BUG: stream = 0, pos = 0x4000, buffer size = 0x4000, period size = 0x200"
That should actually be fixed this patch, I hope it's correct.

Sumary of changes:
- Some volume bug fixes
- SPDIF input fix.
- Clear sample buffer after closing IEC958 stream.
- Ring buffer fix (see my previous mail)
- Some other misses, corrections ....

/Benny

[-- Attachment #2: cs46xx.patch --]
[-- Type: text/plain, Size: 4874 bytes --]

diff --exclude=Makefile --exclude=CVS -Naur alsa-kernel/pci/cs46xx/cs46xx_lib.c ../cvs/alsa-kernel/pci/cs46xx/cs46xx_lib.c
--- alsa-kernel/pci/cs46xx/cs46xx_lib.c	Tue Dec 10 01:34:34 2002
+++ ../cvs/alsa-kernel/pci/cs46xx/cs46xx_lib.c	Tue Dec 10 01:09:48 2002
@@ -849,7 +849,7 @@
 	cpcm->hw_io = ptr;
 	cpcm->hw_ready -= bytes;
 	cpcm->sw_io += bytes;
-	if (cpcm->sw_io > cpcm->sw_bufsize)
+	if (cpcm->sw_io >= cpcm->sw_bufsize)
 		cpcm->sw_io -= cpcm->sw_bufsize;
 	snd_cs46xx_playback_transfer(substream, 0);
 	return cpcm->sw_io >> cpcm->shift;
@@ -874,7 +874,7 @@
 	chip->capt.hw_io = ptr;
 	chip->capt.hw_ready += bytes;
 	chip->capt.sw_io += bytes;
-	if (chip->capt.sw_io > chip->capt.sw_bufsize)
+	if (chip->capt.sw_io >= chip->capt.sw_bufsize)
 		chip->capt.sw_io -= chip->capt.sw_bufsize;
 	snd_cs46xx_capture_transfer(substream, 0);
 	return chip->capt.sw_io >> chip->capt.shift;
@@ -1914,8 +1914,8 @@
 {
 	cs46xx_t *chip = snd_kcontrol_chip(kcontrol);
 
-	ucontrol->value.integer.value[0] = chip->dsp_spos_instance->spdif_input_volume_right;
-	ucontrol->value.integer.value[1] = chip->dsp_spos_instance->spdif_input_volume_left;
+	ucontrol->value.integer.value[0] = chip->dsp_spos_instance->spdif_input_volume_left;
+	ucontrol->value.integer.value[1] = chip->dsp_spos_instance->spdif_input_volume_right;
 	return 0;
 }
 
@@ -1924,8 +1924,8 @@
 	cs46xx_t *chip = snd_kcontrol_chip(kcontrol);
 	int change = 0;
 
-	if (chip->dsp_spos_instance->spdif_input_volume_right != ucontrol->value.integer.value[0] ||
-	    chip->dsp_spos_instance->spdif_input_volume_left != ucontrol->value.integer.value[1]) {
+	if (chip->dsp_spos_instance->spdif_input_volume_left  != ucontrol->value.integer.value[0] ||
+	    chip->dsp_spos_instance->spdif_input_volume_right!= ucontrol->value.integer.value[1]) {
 		cs46xx_dsp_set_iec958_volume (chip,
 					      ucontrol->value.integer.value[0],
 					      ucontrol->value.integer.value[1]);
@@ -2206,6 +2206,7 @@
 }
 
 #endif /* CONFIG_SND_CS46XX_NEW_DSP */
+
 
 #ifdef CONFIG_SND_CS46XX_DEBUG_GPIO
 static int snd_cs46xx_egpio_select_info(snd_kcontrol_t *kcontrol, 
diff --exclude=Makefile --exclude=CVS -Naur alsa-kernel/pci/cs46xx/dsp_spos.c ../cvs/alsa-kernel/pci/cs46xx/dsp_spos.c
--- alsa-kernel/pci/cs46xx/dsp_spos.c	Tue Dec 10 01:34:34 2002
+++ ../cvs/alsa-kernel/pci/cs46xx/dsp_spos.c	Tue Dec 10 01:10:35 2002
@@ -705,7 +705,7 @@
 
 		snd_iprintf(buffer,"%08X ",readl(dst + i));
 	}
-
+#if 0
 	snd_iprintf(buffer,"\nWRITE_BACK_BUF1: \n");
 	col = 0;
 	for (i = WRITE_BACK_BUF1;i < WRITE_BACK_BUF1 + 0x40; i += sizeof(u32),col ++) {
@@ -720,7 +720,22 @@
 
 		snd_iprintf(buffer,"%08X ",readl(dst + i));
 	}
+#endif
+
+	snd_iprintf(buffer,"\nSPDIFI_IP_OUTPUT_BUFFER1: \n");
+	col = 0;
+	for (i = SPDIFI_IP_OUTPUT_BUFFER1;i < SPDIFI_IP_OUTPUT_BUFFER1 + 0x80; i += sizeof(u32),col ++) {
+		if (col == 4) {
+			snd_iprintf(buffer,"\n");
+			col = 0;
+		}
 
+		if (col == 0) {
+			snd_iprintf(buffer, "%04X ",i);
+		}
+		
+		snd_iprintf(buffer,"%08X ",readl(dst + i));
+	}
 	snd_iprintf(buffer,"\n");
 }
 
@@ -1597,6 +1612,9 @@
 	/* reset FIFO ptr */
 	cs46xx_poke_via_dsp (chip,SP_SPDIN_FIFOPTR, 0x0);
 	cs46xx_src_link(chip,ins->spdif_in_src);
+
+	/* unmute SRC volume */
+	cs46xx_dsp_scb_set_volume (chip,ins->spdif_in_src,0x7fff,0x7fff);
 
 	spin_unlock_irq(&chip->reg_lock);
 
diff --exclude=Makefile --exclude=CVS -Naur alsa-kernel/pci/cs46xx/dsp_spos.h ../cvs/alsa-kernel/pci/cs46xx/dsp_spos.h
--- alsa-kernel/pci/cs46xx/dsp_spos.h	Sun Dec  8 13:21:55 2002
+++ ../cvs/alsa-kernel/pci/cs46xx/dsp_spos.h	Tue Dec 10 00:42:21 2002
@@ -197,7 +197,7 @@
 		((val & 0x10) >> 1) |
 		((val & 0x20) >> 3) |
 		((val & 0x40) >> 5) |
-		((val & 0x80) >> 6);
+		((val & 0x80) >> 7);
 
 	return wrapped;
 
diff --exclude=Makefile --exclude=CVS -Naur alsa-kernel/pci/cs46xx/dsp_spos_scb_lib.c ../cvs/alsa-kernel/pci/cs46xx/dsp_spos_scb_lib.c
--- alsa-kernel/pci/cs46xx/dsp_spos_scb_lib.c	Tue Dec 10 01:34:35 2002
+++ ../cvs/alsa-kernel/pci/cs46xx/dsp_spos_scb_lib.c	Tue Dec 10 00:58:33 2002
@@ -1270,8 +1270,8 @@
 	}
 
 	if (pcm_channel_id == DSP_IEC958_CHANNEL && sample_rate == 48000) {
-		snd_assert (ins->spdif_pcm_input_scb = NULL);
-
+		snd_assert (ins->spdif_pcm_input_scb == NULL);
+		
 		/* a hack to make the skip the SRC and pass the stream 
 		   directly to the SPDIF task */
 		ins->spdif_pcm_input_scb = 
@@ -1281,7 +1281,7 @@
 							       ins->asynch_tx_scb,
 							       SCB_ON_PARENT_SUBLIST_SCB);		
 	}
-
+	
 	spin_lock_irqsave(&chip->reg_lock, flags);
 	ins->pcm_channels[pcm_index].sample_rate = sample_rate;
 	ins->pcm_channels[pcm_index].pcm_reader_scb = pcm_scb;
@@ -1664,6 +1664,9 @@
 
 	cs46xx_dsp_remove_scb (chip,ins->asynch_tx_scb);
 	ins->asynch_tx_scb = NULL;
+
+	/* clear buffer to prevent any undesired noise */
+	_dsp_clear_sample_buffer(chip,SPDIFO_IP_OUTPUT_BUFFER1,256);
 
 	/* restore state */
 

Re: [PATCH] cs46xx some few corrections

[Friedrich Ewaldt]

Hi Benny!

Many thanks for this new patch! Now the xrun problems I reported are 
gone (great!), the SPDIF volume slider works correctly and SPDIF input 
basically works again.
There seems to remain one problem with SPDIF input that wasn't there 
with rc6: With rc6, SPDIF input got out of sync sometimes. 
Muting+unmuting SPDIF input solved this problem. With the newest 
driver+last 2 patches, the SPDIF input sound is very distorted. After 
loading the alsa driver it sounds very 'robotic' (don't know how to 
describe it :-)) and high frequency components are missing. After 
muting+unmuting SPDIF input approx. 10 times SPDIF input gets into 
another state and there are many high frequency distortions. These 
distortions (not this pure high freq tone, I don't get this anymore) 
remain whenever I switch on SPDIF input. I didn't manage to get 
undistorted SPDIF input (which was possible with rc6). 
Dis-/reconnetcting the SPDIF input cable didn't help either.
Another issue regarding SPDIF: Digital input works sometimes when I 
reboot, sometimes it doesn't (restarting alsa doesn't help then) and I 
have to reboot once again (I don't see a pattern why it does/-not work 
sometimes). SPDIF input always works when I do a soft reboot from win98, 
i.e. the card seems to be initialized by the win driver somehow (would 
some /proc/asound dumps help solving this problem?). Do you have similar 
problems with your card? Maybe that's terratec xfire specific. Anyone 
out there with a xfire who can report about SPDIF input with this card?

Again, many thanks for your work on this driver!
fe

Benny Sjostrand schrieb:

> Hi!
>
> If the SPDIF input worked with rc6 it should work now with this patch, 
> the SPDIF input "Source Rate Converter"-SCB
> was muted all the time and that should fixed by now.
> I discovered that AC3 almost works but get very easily out of sync in 
> some how (got no solution for this yet)
> Restarting the application about ~ 10 times, eg. with xine press 
> PLAY-STOP PLAY-STOP ... until you get
> sound.
> There was/is actually a ring buffer problem in the cs46xx driver 
> giving this kind of outputs (see my previous mail):
> "Dec 8 13:40:16 cactus kernel: ALSA ../alsa-kernel/core/pcm_lib.c:176: 
> BUG: stream = 0, pos = 0x4000, buffer size = 0x4000, period size = 0x200"
> That should actually be fixed this patch, I hope it's correct.
>
> Sumary of changes:
> - Some volume bug fixes
> - SPDIF input fix.
> - Clear sample buffer after closing IEC958 stream.
> - Ring buffer fix (see my previous mail)
> - Some other misses, corrections ....
>
> /Benny
>





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

Re: [PATCH] cs46xx some few corrections

[Takashi Iwai]

At Tue, 10 Dec 2002 09:09:25 +0100,
Benny Sjostrand wrote:
> 
> Hi!
> 
> If the SPDIF input worked with rc6 it should work now with this patch, 
> the SPDIF input "Source Rate Converter"-SCB
> was muted all the time and that should fixed by now.
> I discovered that AC3 almost works but get very easily out of sync in 
> some how (got no solution for this yet)
> Restarting the application about ~ 10 times, eg. with xine press 
> PLAY-STOP PLAY-STOP ... until you get
> sound.
> There was/is actually a ring buffer problem in the cs46xx driver giving 
> this kind of outputs (see my previous mail):
> "Dec 8 13:40:16 cactus kernel: ALSA ../alsa-kernel/core/pcm_lib.c:176: 
> BUG: stream = 0, pos = 0x4000, buffer size = 0x4000, period size = 0x200"
> That should actually be fixed this patch, I hope it's correct.
> 
> Sumary of changes:
> - Some volume bug fixes
> - SPDIF input fix.
> - Clear sample buffer after closing IEC958 stream.
> - Ring buffer fix (see my previous mail)
> - Some other misses, corrections ....

applied.  thanks for your patch!


Takashi


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

Re: [PATCH] cs46xx some few corrections

[Benny Sjostrand]

> Many thanks for this new patch! Now the xrun problems I reported are 
> gone (great!), the SPDIF volume slider works correctly and SPDIF input 
> basically works again.
> There seems to remain one problem with SPDIF input that wasn't there 
> with rc6: With rc6, SPDIF input got out of sync sometimes. 
> Muting+unmuting SPDIF input solved this problem. With the newest 
> driver+last 2 patches, the SPDIF input sound is very distorted. After 
> loading the alsa driver it sounds very 'robotic' (don't know how to 
> describe it :-)) and high frequency components are missing. After 
> muting+unmuting SPDIF input approx. 10 times SPDIF input gets into 
> another state and there are many high frequency distortions. These 
> distortions (not this pure high freq tone, I don't get this anymore) 
> remain whenever I switch on SPDIF input. I didn't manage to get 
> undistorted SPDIF input (which was possible with rc6). 
> Dis-/reconnetcting the SPDIF input cable didn't help either.
> Another issue regarding SPDIF: Digital input works sometimes when I 
> reboot, sometimes it doesn't (restarting alsa doesn't help then) and I 
> have to reboot once again (I don't see a pattern why it does/-not work 
> sometimes). SPDIF input always works when I do a soft reboot from 
> win98, i.e. the card seems to be initialized by the win driver somehow 
> (would some /proc/asound dumps help solving this problem?). Do you 
> have similar problems with your card? Maybe that's terratec xfire 
> specific. Anyone out there with a xfire who can report about SPDIF 
> input with this card?

The SPDIF input problems are known (at least to me) and not specific to 
the xfire card. The main problem is that I dont have enough of technical 
info about to implement the SPDIF input part. The only answer I got from 
a developer at Cirrus regarding the SPDIF input part was something like: 
"yeahh, the SPDIF input needs some special treatments but in this moment 
I dont remember exactly what" now several months has passed and I have 
not heard a single word from Cirrus (got no responses to my mails at all 
anymore ...)

So, so i am afraid that it wont be better than that for the moment ...

/Benny




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: [PATCH] cs46xx some few corrections

[Friedrich Ewaldt]

Hi!

Too bad Cirrus doesn't like it's circuits to be used. Why can't they
just release the source code of the driver for this CS4624/4630. I
thought this circuit wasn't up to date any more. Maybe there are too
many bugs they don't want to be seen by anyone ;-)

As Cirrus doesn't help in the moment, do you have an idea why I managed
to get perfect sounding SPDIF input (after switching off/on the input 3
times or so) with 0.9.0rc6 and why I don't get undistorted sound with
cvs+latest patch? Could you see what loading the win driver before
booting into linux changes on the card if I would send some proc/asound/
dumps?
Thanks!
fe




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: [PATCH] cs46xx some few corrections

[Benny Sjostrand]

> As Cirrus doesn't help in the moment, do you have an idea why I managed
> to get perfect sounding SPDIF input (after switching off/on the input 3
> times or so) with 0.9.0rc6 and why I don't get undistorted sound with
> cvs+latest patch? Could you see what loading the win driver before
> booting into linux changes on the card if I would send some proc/asound/
> dumps?
> Thanks!

You right, it must possible to get it that good as it was
in rc6. I'll will investigate in on this.

/Benny



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: [PATCH] cs46xx some few corrections

[Kevin Puetz]

> > Sumary of changes:
> > - Some volume bug fixes
> > - SPDIF input fix.
> > - Clear sample buffer after closing IEC958 stream.
> > - Ring buffer fix (see my previous mail)
> > - Some other misses, corrections ....
>
> applied.  thanks for your patch!

nice, now alsa cvs and the cs46xx are best friends again :-)

Any chance of getting a 2.5 merge sometime soon (since it doesn't seem that 
the current cs46xx builds if dropped into a 2.5 tree)? It sure would be nice 
to have the phase problems fixed there as well.

If there's supposed to be a way to build the alsa cvs against 2.5, that would 
be fine too, but I couldn't figure it out.

> Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: [PATCH] cs46xx some few corrections

[Takashi Iwai]

At Wed, 18 Dec 2002 08:00:50 -0600,
Kevin Puetz wrote:
> 
> > > Sumary of changes:
> > > - Some volume bug fixes
> > > - SPDIF input fix.
> > > - Clear sample buffer after closing IEC958 stream.
> > > - Ring buffer fix (see my previous mail)
> > > - Some other misses, corrections ....
> >
> > applied.  thanks for your patch!
> 
> nice, now alsa cvs and the cs46xx are best friends again :-)
> 
> Any chance of getting a 2.5 merge sometime soon (since it doesn't seem that 
> the current cs46xx builds if dropped into a 2.5 tree)? It sure would be nice 
> to have the phase problems fixed there as well.

Jaroslav already posted the latest bk-patch, so hopefully it will be
merged by Linus soon.


> If there's supposed to be a way to build the alsa cvs against 2.5, that would 
> be fine too, but I couldn't figure it out.

basically, you can just copy alsa-kernel directories on 2.5 tree.
the directory structure is a bit different like the following:

alsa-kernel/include	-> linux/include/sound
alsa-kernel/Documentation -> linux/Documentation/alsa
alsa-kernel/scripts	-> skip (contains only helper scripts)
alsa-kernel/oss		-> skip (it's empty)
alsa-kernel/core, and others
			-> linux/sound/core, etc.

don't forget to reserve the old linux/sound/oss directory.
alsa-kernel/oss directory contains nothing, of course :)


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: [PATCH] cs46xx some few corrections

[Jaroslav Kysela]

On Wed, 18 Dec 2002, Kevin Puetz wrote:

> > > Sumary of changes:
> > > - Some volume bug fixes
> > > - SPDIF input fix.
> > > - Clear sample buffer after closing IEC958 stream.
> > > - Ring buffer fix (see my previous mail)
> > > - Some other misses, corrections ....
> >
> > applied.  thanks for your patch!
> 
> nice, now alsa cvs and the cs46xx are best friends again :-)
> 
> Any chance of getting a 2.5 merge sometime soon (since it doesn't seem that 
> the current cs46xx builds if dropped into a 2.5 tree)? It sure would be nice 
> to have the phase problems fixed there as well.
> 
> If there's supposed to be a way to build the alsa cvs against 2.5, that would 
> be fine too, but I couldn't figure it out.

There's no direct way, but everything in alsa-kernel is propagated to 2.5
tree by hand (or better the ksync script - alsa-kernel/scripts/ksync - and
my manual verification), but you need a BK repository.

The BK repository at http://linux-sound.bkbits.net/linux-sound contains my 
last "sync" stuff, also patches against 2.5 kernel tree can be found at
ftp://ftp.alsa-project.org/pub/kernel-patches .

						Jaroslav

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



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/