[PATCH] cs46xx: Center-LFE channel support + a lot of hacking

[PATCH] cs46xx: Center-LFE channel support + a lot of hacking

[Benny Sjostrand]

Hi!

I've been working of lot things, hopefully all theese changes can 
integrated painless.

Pathes are available for download at:
http://www.cucumelo.org/~gorm/cs46xx.patch  (for 
alsa-kernel/pci/cs46xx/* changes)
http://www.cucumelo.org/~gorm/cs46xx_include.patch (for 
alsa-kernel/include/* changes)

The main new feuture is a new PCM channel:
- Cards with a dual CODEC configuration (2 x cs4294 || 1 x cs4297A + 1 x 
cs4294),
like (Hercules GTXP, Santa Cruz, Terratec SixPack 5.1):
    PCM 0 - slot 3 and 4 (Primary CODEC) main channel
    PCM 1 - slot 7 and 8 (Seconadry CODEC) rear channel
    PCM 2 - IEC958, SPDIF output from the DSP
    PCM 3 - slot 6 and 9 (Seconadry CODEC) left channel is Center and 
right is LFE

    Theoretically it should also possible to support yet another analog 
output on
     slot 11 and 5 on primary CODEC, to support surround 7.1, (Hercules GTXP
     has done something here, but dont exaclty how stuff are wired ...)
- Cards with a single CODEC configuration (1 x cs4294), like Terratec 
XFire 1024:
    (This configuration is untested)
    PCM 0 - slot 3 and 4 (Primary CODEC) main channel
    PCM 1 - slot 11 and 5 (Primary CODEC) rear channel
    PCM 2 - IEC958, SPDIF output from the DSP


- Some changes to the IEC958 input, should be functional by now, but 
still far from
being perfect.

- There is another theoretical problem which will prevent the cs46xx 
work on Big Endian
 architectures. I've started to work on this issue, but not finished yet.
 What's left on this point is to initialize all DSP structs with the C99 
style (.member = value, ...)
 a lot of painful work (anyone like to help me ? -;) )

Known problems (for the moment):
- The Terratec SixPack 5.1 card wont initialize correctly on a cold/warm 
boot.
   A reload of the ALSA driver fixes the problem.
- The IEC958 input port sometimes just stop working, the only thing that 
seems
   to fix it is a cold boot. (a warm reboot does not seems to be enough)
- The analog output's on the SiXPack 5.1 are very distorcionated when 
PCM volumes
 is over ~ 65 %. The only amplified output on this cards seems to be the 
Headphone output.

That's all for now ...

/Benny



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

Re: [PATCH] cs46xx: Center-LFE channel support + a lot of hacking

[Takashi Iwai]

At Sun, 30 Mar 2003 20:51:14 +0200,
Benny Sjostrand wrote:
> 
> Hi!
> 
> I've been working of lot things, hopefully all theese changes can 
> integrated painless.
> 
> Pathes are available for download at:
> http://www.cucumelo.org/~gorm/cs46xx.patch  (for 
> alsa-kernel/pci/cs46xx/* changes)
> http://www.cucumelo.org/~gorm/cs46xx_include.patch (for 
> alsa-kernel/include/* changes)

thanks, i committed to cvs now (together with the change of .conf).


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [PATCH] cs46xx: Center-LFE channel support + a lot of hacking

[Friedrich Ewaldt]

Hi Benny,

I just tested your patches with my terratec DMX XFire 1024. Rear channel 
doesn't seem to work as intended:
I always get the same output out of both output jacks when I play back 
on hw:0,0 (should be on the first/front output only, I assume).
I can't hear anything from the analog outputs when playing back on 
hw:0,1 (this should be the second output, correct?).
I.e. the behaviour of the analog outputs of the XFire seems to not have 
changed.

SPDIF input no works basically again (it worked up to rc6, afterwards, 
no non-distorted digital recording was possible with the XFire -- up to 
your newest great patches :) ). That's a really great improvement! Many 
thanks for this.
I noticed that I can't change SPDIF input volume any more. Is this 
intended? For me that's o.k. For recordings it's even better to have no 
additional scaling.
SPDIF sounds good, as far I can hear with not-too-expensive headphones 
near my not-too-silent computer. But as I've looked at a spectrogram 
(short time spectra of short time windows), I noticed there are some 
errors (spikes) approx. every 0.24 second. You can see these as thin 
vertical lines that shouldn't be there in the plot I've attached. The 
errors are not very severe: Most of them you can't seen in the time 
signal, even if you know where they are an zoom into the signal ;)
I don't get these spikes when recording from analog sources or when 
recording from SPDIF under win98. Not really true: sometimes I get them 
also under win98, if I introduce many biterrors by 
disonnecting/connecting the digital input cable several times. 
Theoretically the SPDIF input should resync to the audio stream 
afterwards, but sometimes it doesn't, even with the 'original' win 
driver. Under win98, I can solve this problem by switching SPDIF input 
off/on in the driver panel.

so far my first results with the new patches. The SPDIF input results 
are very encouraging that this card will get more and more useful under 
linux thanks to your work...
  fe

Benny Sjostrand wrote:

> Hi!
>
> I've been working of lot things, hopefully all theese changes can 
> integrated painless.
>
> Pathes are available for download at:
> http://www.cucumelo.org/~gorm/cs46xx.patch  (for 
> alsa-kernel/pci/cs46xx/* changes)
> http://www.cucumelo.org/~gorm/cs46xx_include.patch (for 
> alsa-kernel/include/* changes)
>
> The main new feuture is a new PCM channel:
> - Cards with a dual CODEC configuration (2 x cs4294 || 1 x cs4297A + 1 
> x cs4294),
> like (Hercules GTXP, Santa Cruz, Terratec SixPack 5.1):
>    PCM 0 - slot 3 and 4 (Primary CODEC) main channel
>    PCM 1 - slot 7 and 8 (Seconadry CODEC) rear channel
>    PCM 2 - IEC958, SPDIF output from the DSP
>    PCM 3 - slot 6 and 9 (Seconadry CODEC) left channel is Center and 
> right is LFE
>
>    Theoretically it should also possible to support yet another analog 
> output on
>     slot 11 and 5 on primary CODEC, to support surround 7.1, (Hercules 
> GTXP
>     has done something here, but dont exaclty how stuff are wired ...)
> - Cards with a single CODEC configuration (1 x cs4294), like Terratec 
> XFire 1024:
>    (This configuration is untested)
>    PCM 0 - slot 3 and 4 (Primary CODEC) main channel
>    PCM 1 - slot 11 and 5 (Primary CODEC) rear channel
>    PCM 2 - IEC958, SPDIF output from the DSP
>
>
> - Some changes to the IEC958 input, should be functional by now, but 
> still far from
> being perfect.
>
> - There is another theoretical problem which will prevent the cs46xx 
> work on Big Endian
> architectures. I've started to work on this issue, but not finished yet.
> What's left on this point is to initialize all DSP structs with the 
> C99 style (.member = value, ...)
> a lot of painful work (anyone like to help me ? -;) )
>
> Known problems (for the moment):
> - The Terratec SixPack 5.1 card wont initialize correctly on a 
> cold/warm boot.
>   A reload of the ALSA driver fixes the problem.
> - The IEC958 input port sometimes just stop working, the only thing 
> that seems
>   to fix it is a cold boot. (a warm reboot does not seems to be enough)
> - The analog output's on the SiXPack 5.1 are very distorcionated when 
> PCM volumes
> is over ~ 65 %. The only amplified output on this cards seems to be 
> the Headphone output.
>
> That's all for now ...
>
> /Benny
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>
>




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: [PATCH] cs46xx: Center-LFE channel support + a lot of hacking

[Benny Sjostrand]

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

> I just tested your patches with my terratec DMX XFire 1024. Rear 
> channel doesn't seem to work as intended:
> I always get the same output out of both output jacks when I play back 
> on hw:0,0 (should be on the first/front output only, I assume).
> I can't hear anything from the analog outputs when playing back on 
> hw:0,1 (this should be the second output, correct?).
> I.e. the behaviour of the analog outputs of the XFire seems to not 
> have changed. 


Untested code is condemned to fail. Once again reading the cs4294 spec. 
I think I got an explication for this (see the 6.1.30 section, EAM bit ...)
So, I got a patch the hopefully would bring 4 channel sound for the 
XFire 1024 card. Please, would you like help testing it ?? and tell 
about the results ...

>
> SPDIF input no works basically again (it worked up to rc6, afterwards, 
> no non-distorted digital recording was possible with the XFire -- up 
> to your newest great patches :) ). That's a really great improvement! 
> Many thanks for this.
> I noticed that I can't change SPDIF input volume any more. Is this 
> intended? For me that's o.k. For recordings it's even better to have 
> no additional scaling. 

 Good to hear that the SPDIF input parts is functional again. I've not 
been able to test this parts course the SPDIF input on my Hercules GTXP 
card does not work at all since a couple a month agoo. I'm suspecting 
the HW, like I manage to burn it up with all weird experiments. Now with 
my new Terratec SiXPack 5.1 finally I've been able to do some tests again.

About the volume, there is not any code in the DSP that scales the 
samples anymore since I've change the tasklet with the last patch. The 
DSP tasklet that receives the input samples from the SPDIF input is very 
dummy, it just moves the samples to the output mixer, without doing any 
procesing at all (the same tasklet used for SPDIF pass-through) Another 
limitation is that no other sample-rate than 48khz will work, the 
CODEC's native sample-rate, as we for the moment dont know how to detect 
the incoming sample-rate, and setup a working sample-rate-converter 
tasklet it really dont matter ...

>
> SPDIF sounds good, as far I can hear with not-too-expensive headphones 
> near my not-too-silent computer. But as I've looked at a spectrogram 
> (short time spectra of short time windows), I noticed there are some 
> errors (spikes) approx. every 0.24 second. You can see these as thin 
> vertical lines that shouldn't be there in the plot I've attached. The 
> errors are not very severe: Most of them you can't seen in the time 
> signal, even if you know where they are an zoom into the signal ;) 

Sorry, I dont see any atachment in the mail ?

>
> I don't get these spikes when recording from analog sources or when 
> recording from SPDIF under win98. Not really true: sometimes I get 
> them also under win98, if I introduce many biterrors by 
> disonnecting/connecting the digital input cable several times. 
> Theoretically the SPDIF input should resync to the audio stream 
> afterwards, but sometimes it doesn't, even with the 'original' win 
> driver. Under win98, I can solve this problem by switching SPDIF input 
> off/on in the driver panel.

Seems like it has been hard even for the Cirrus developers to make the 
SPDIF input parts to work.

>
> so far my first results with the new patches. The SPDIF input results 
> are very encouraging that this card will get more and more useful 
> under linux thanks to your work...
>  fe
>
Thanks! always nice to hear some positive words :)

/Benny

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

--- alsa-kernel/pci/cs46xx/cs46xx_lib.c	Sat Apr  5 21:09:20 2003
+++ ../cvs/alsa-kernel/pci/cs46xx/cs46xx_lib.c	Sat Apr  5 21:22:58 2003
@@ -2543,13 +2543,21 @@
 	chip->eapd_switch = snd_ctl_find_id(chip->card, &id);
     
 #ifdef CONFIG_SND_CS46XX_NEW_DSP
+	if (chip->nr_ac97_codecs == 1 && 
+	   snd_cs46xx_codec_read(chip,AC97_VENDOR_ID2,
+				 CS46XX_PRIMARY_CODEC_INDEX) == 0x5d2d) {
+		/* set primary cs4294 codec into Extended Audio Mode */
+		snd_printdd("setting EAM bit on cs4294 CODEC\n");
+		snd_cs46xx_codec_write(chip,AC97_CSR_ACMODE,0x200,
+				       CS46XX_PRIMARY_CODEC_INDEX);
+	}
 	/* do soundcard specific mixer setup */
 	if (chip->mixer_init) {
 		snd_printdd ("calling chip->mixer_init(chip);\n");
 		chip->mixer_init(chip);
 	}
 #endif
-
+	
  	/* turn on amplifier */
 	chip->amplifier_ctrl(chip, 1);
     

cs46xx -> Terratec DMX XFire 1024 4channel output success

[Friedrich Ewaldt]

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

Tataaa!
I got output of 4 independent channels from my XFire for the first time 
under linux!

Benny Sjostrand wrote:

>
> Untested code is condemned to fail. Once again reading the cs4294 
> spec. I think I got an explication for this (see the 6.1.30 section, 
> EAM bit ...)
> So, I got a patch the hopefully would bring 4 channel sound for the 
> XFire 1024 card. Please, would you like help testing it ?? and tell 
> about the results ... 

sorry, I don't have the spec. And I think it would take some time for me 
to understand what's going on *exactly*.
So I just applied your last patch. But in the beginning it didn't change 
anything. I had a look on the code of your patch and saw this
snd_printdd("setting EAM bit on cs4294 CODEC\n");
line. Therefore I recompiled with --with-debug=detect, installed once 
again and switched on the syslogd on my system. I attached the cs46xx 
specific output as messages.gz to this mail. As you can see, the EAM 
message is not printed.
I commented out your check for the codec type:

    if (1){   //(chip->nr_ac97_codecs == 1 &&
//       snd_cs46xx_codec_read(chip,AC97_VENDOR_ID2,
//                 CS46XX_PRIMARY_CODEC_INDEX) == 0x5d2d) {
        /* set primary cs4294 codec into Extended Audio Mode */

recompiled, reinstalled and...
... 4 channel output works!!!
It seems like I cannot change the output volume of the back('headphone') 
channels. The PCM slider only controls the first('front') output.

What information do you need to get the codec check working (alsamixer 
tells me 'Cirrus Logic CS4294 rev 5'). Just tell me what I should do :)

>
> [...]
> About the volume, there is not any code in the DSP that scales the 
> samples anymore since I've change the tasklet with the last patch. The 
> DSP tasklet that receives the input samples from the SPDIF input is 
> very dummy, it just moves the samples to the output mixer, without 
> doing any procesing at all (the same tasklet used for SPDIF 
> pass-through) Another limitation is that no other sample-rate than 
> 48khz will work, the CODEC's native sample-rate, as we for the moment 
> dont know how to detect the incoming sample-rate, and setup a working 
> sample-rate-converter tasklet it really dont matter ...

48kHz is no problem for me, as I'm using an ADR (astra digital radio) as 
source which outputs 48 kHz.

>
>>
>> SPDIF sounds good, as far I can hear with not-too-expensive 
>> headphones near my not-too-silent computer. But as I've looked at a 
>> spectrogram (short time spectra of short time windows), I noticed 
>> there are some errors (spikes) approx. every 0.24 second. You can see 
>> these as thin vertical lines that shouldn't be there in the plot I've 
>> attached. The errors are not very severe: Most of them you can't seen 
>> in the time signal, even if you know where they are an zoom into the 
>> signal ;) 
>
>
> Sorry, I dont see any atachment in the mail ?
>
something went wrong, I don't know what, but I tried again to attach it 
to this mail once again...

So, many thanks for the last patch. That's a great step ahead!

  fe


[-- Attachment #2: spdif_cs46xx.jpg --]
[-- Type: image/jpeg, Size: 14000 bytes --]

[-- Attachment #3: messages.gz --]
[-- Type: application/gzip, Size: 1934 bytes --]

Re: cs46xx -> Terratec DMX XFire 1024 4channel output success

[Benny Sjostrand]

> sorry, I don't have the spec. And I think it would take some time for 
> me to understand what's going on *exactly*.
> So I just applied your last patch. But in the beginning it didn't 
> change anything. I had a look on the code of your patch and saw this
> snd_printdd("setting EAM bit on cs4294 CODEC\n");
> line. Therefore I recompiled with --with-debug=detect, installed once 
> again and switched on the syslogd on my system. I attached the cs46xx 
> specific output as messages.gz to this mail. As you can see, the EAM 
> message is not printed.
> I commented out your check for the codec type:
>
>    if (1){   //(chip->nr_ac97_codecs == 1 &&
> //       snd_cs46xx_codec_read(chip,AC97_VENDOR_ID2,
> //                 CS46XX_PRIMARY_CODEC_INDEX) == 0x5d2d) {
>        /* set primary cs4294 codec into Extended Audio Mode */
>
> recompiled, reinstalled and...
> ... 4 channel output works!!!
> It seems like I cannot change the output volume of the 
> back('headphone') channels. The PCM slider only controls the 
> first('front') output.
>
> What information do you need to get the codec check working (alsamixer 
> tells me 'Cirrus Logic CS4294 rev 5'). Just tell me what I should do :)
>

The intention with that if(...) statment was to make sure that there was 
only one codec available and that codec was a cs4294.

Could you test it again chaning the "0x5d2d" to "0x592d" ? (my misstake ...)
If that dont work could you send me a dump of /proc/asound/card0/ac97#0regs

I believe it should be possible to control the volume from the second 
output, just need to find out how, so I'll try to find something in the 
bloody cs4294 spec., well, and hopefully something will happen to the 
code ;)

/Benny



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: cs46xx -> Terratec DMX XFire 1024 4channel output success

[Friedrich Ewaldt]

Hi Benny,

Benny Sjostrand wrote:

>
> The intention with that if(...) statment was to make sure that there 
> was only one codec available and that codec was a cs4294.
>
> Could you test it again chaning the "0x5d2d" to "0x592d" ? (my 
> misstake ...)
> If that dont work could you send me a dump of 
> /proc/asound/card0/ac97#0regs

Yep, 0x592d works perfectly and I also find that "0x592d" as last output 
of /proc/asound/card0/ac97#0regs.

>
> I believe it should be possible to control the volume from the second 
> output, just need to find out how, so I'll try to find something in 
> the bloody cs4294 spec., well, and hopefully something will happen to 
> the code ;) 

Just to get sure you didn't misunderstand me :)
Volume control of the second output DOES work (using the 'headphones' 
slider), but the 'PCM' slider only controls the first output's volume.

I think I'm beginning to understand why:
The second output is a pure PCM output, i.e. no mixing of CD, line-in, 
mic-in, ... as for the first output. Therefore, there is only *one* 
mixer element to control the second output. Only the name "headphones" 
is misleading.
In the new 4 channel configuration this control could have been named 
"PCM2" or "rear PCM" or ...
... or isn't "headphones" sometimes the correct name?

That leads to the next point:
Is it possible to switch back to the oly behaviour at run time? (seem 
like the decision in which mode to initialize the codec is done while 
starting alsa). Using the second output as a headphone output of the 
first PCM device is not completely wrong: On the XFire there are jumpers 
which you can use to select the output type (amplified for loudspeakers 
-or- line level) of the *first* output only. The second output is always 
at line level, i.e. suitable for 600Ohm headphones.
I don't know whether it's a good idea to allow switching back to the 
2channel ("front-back-always-the-same-sound") for using headphones to 
hear at the first output.
I think there is an alternative: It should be possible to copy the data 
from the first output to the second output by some .asoundrc magic. But: 
how much CPU time will alsa eat for this (keeping in mind that the codec 
itself can do the same without any CPU cost)? If it's not too much, I 
wouldn't see any reason for switching back to the old codec configuration.
What do you think? (I know, you don't have the XFire, but anyway ;-) )
  fe



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Re: cs46xx -> Terratec DMX XFire 1024 4channel output success

[Benny Sjostrand]

> Yep, 0x592d works perfectly and I also find that "0x592d" as last 
> output of /proc/asound/card0/ac97#0regs. 


Great!

> Just to get sure you didn't misunderstand me :)
> Volume control of the second output DOES work (using the 'headphones' 
> slider), but the 'PCM' slider only controls the first output's volume.
>
> I think I'm beginning to understand why:
> The second output is a pure PCM output, i.e. no mixing of CD, line-in, 
> mic-in, ... as for the first output. Therefore, there is only *one* 
> mixer element to control the second output. Only the name "headphones" 
> is misleading.
> In the new 4 channel configuration this control could have been named 
> "PCM2" or "rear PCM" or ...
> ... or isn't "headphones" sometimes the correct name?

Yeah that make sense, I was about to ask you if did'nt have a 
"Headphone" control in your mixer.

About the "Headphone" maybe a more correct name could be "Alternate 
Output", well, dont know, as that is done in the ac97 layer.

>
> That leads to the next point:
> Is it possible to switch back to the oly behaviour at run time? (seem 
> like the decision in which mode to initialize the codec is done while 
> starting alsa). Using the second output as a headphone output of the 
> first PCM device is not completely wrong: On the XFire there are 
> jumpers which you can use to select the output type (amplified for 
> loudspeakers -or- line level) of the *first* output only. The second 
> output is always at line level, i.e. suitable for 600Ohm headphones.
> I don't know whether it's a good idea to allow switching back to the 
> 2channel ("front-back-always-the-same-sound") for using headphones to 
> hear at the first output.
> I think there is an alternative: It should be possible to copy the 
> data from the first output to the second output by some .asoundrc 
> magic. But: how much CPU time will alsa eat for this (keeping in mind 
> that the codec itself can do the same without any CPU cost)? If it's 
> not too much, I wouldn't see any reason for switching back to the old 
> codec configuration.
> What do you think? (I know, you don't have the XFire, but anyway ;-) )
>  fe

To get back to the previous mode, it's just to unset the EAM bit. Maybe 
we could have a control in the mixer for that like "4 channel 
duplicate", or something that just unset/set the EAM bit when desired.

/Benny




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/