cs46xx -> Terratec DMX XFire 1024 4channel output success

[Friedrich Ewaldt <friedrich.ewaldt@gmx.de>]

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