SPDIF output finally working properly with CS4630

SPDIF output finally working properly with CS4630

[Benny Sjostrand]

Hi!

After a lot fustrated hacking nights and days, finally (at least) I 
manage to get a properly sound out from SPDIF interface on my Hercules 
Game Theater XP card, at least "so far as i can hear". The sound is no 
longer distorcionated and SPDIF is now integrated with the ALSA mixer 
(muted by default).

About other missing basic feutures, SPDIF input, 4 channels, multi PCM 
etc., well, I'm working on that, we see what I can do, at least there is 
a hope ...

The code is still very dirty, noisy, well, I know that it needs a lot of 
cleanup.

My new current snapshots:
http://www.cucumelo.org/~gorm/alsa-driver-0.9.0rc2-bs20020723.tar.gz
http://www.cucumelo.org/~gorm/ospparser.tar.gz

Please, test it and give some feedback, maybe there are things that was 
working before
and are now broken., etc ...

but,
NOTE the code is very EXPERIMENTAL and may be very UNSTABLE for the moment.

/Benny



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

Re: SPDIF output finally working properly with CS4630

[Peter Heatwole]

On 2002.07.23 13:33 Benny Sjostrand wrote:
> About other missing basic feutures, SPDIF input, 4 channels, multi PCM 
> etc., well, I'm working on that, we see what I can do, at least there is
> a hope ...
[...]
> Please, test it and give some feedback, maybe there are things that was 
> working before
> and are now broken., etc ...


    I've downloaded and installed your driver, but it seems that something
has changed in CVS since the rc2 release. Here's the error I'm getting:


[peter@porky als]$ aplay footsteps.wav Playing WAVE 'footsteps.wav' : 
Signed 16 bit Little Endian, Rate 44100 Hz, Mono
aplay: interval_inline.h:65: snd_interval_min: Assertion 
`!snd_interval_empty(i)' failed.
Aborted...


    I'm using the CVS of all the ALSA packages. I'm very interested
in S/PDIF output on my Santa Cruz, and will be watching your releases
with earnest.
    One request, however: would you release the files by themselves?
(versus the whole alsa-driver-0.9.0rc2 package)  I didn't have time
to check, but are you modifying anything beyond files in the
pci/cs46xx folder?

    I tested the driver with CVS and your package as a whole, with
the same response. Could it be something in alsa-lib that's changed?

Good luck!

-- Peter Heatwole
"Murphy was just a well known pessimist."



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

Re: SPDIF output finally working properly with CS4630

[Benny Sjostrand]

> [peter@porky als]$ aplay footsteps.wav Playing WAVE 'footsteps.wav' : 
> Signed 16 bit Little Endian, Rate 44100 Hz, Mono
> aplay: interval_inline.h:65: snd_interval_min: Assertion 
> `!snd_interval_empty(i)' failed.
> Aborted... 


oops!

I guess that maybe you need to alsa-lib-0.9.0rc2, everything *0.9.0rc2, 
thats what's i got installed.

Now I've generated a patch against alsa-driver-0.9.0rc2, so you can try 
to merge it with your CVS snapshot,
maybe it works better ....

http://www.cucumelo.org/~gorm/alsa-driver-0.9.0rc2-bs20020723.diff.gz

/Benny



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

Re: SPDIF output finally working properly with CS4630

[Peter Heatwole]

On 2002.07.23 21:28 Benny Sjostrand wrote:
> Now I've generated a patch against alsa-driver-0.9.0rc2, so you can try 
> to merge it with your CVS snapshot,
> maybe it works better ....

    Thanks. It took a tad of modifying to patch the CVS because it was
expecting a 0.9.0rc2 postfix on everything, but that was simple to fix.
    I patched the CVS, and am getting the same error. I stuck the following
into alsa-lib/src/pcm/interval_inline.h, and am getting some feedback on
what's going wrong:

printf("snd_interval_min()::: i->empty == %d\n", i->empty)

<<<which results in>>>

[peter@porky als]$ aplay footsteps.wav Playing WAVE 'footsteps.wav' : 
Signed 16 bit Little Endian, Rate 44100 Hz, Mono
snd_interval_min():::  i->empty == 0
snd_interval_min():::  i->empty == 0
snd_interval_min():::  i->empty == 0
snd_interval_min():::  i->emtpy == 0
snd_interval_min():::  i->empty == 1
aplay: interval_inline.h:66: snd_interval_min: Assertion 
`!snd_interval_empty(i)' failed.
Aborted...


    Also, I tried the driver with the xmms-alsa plugin, and it
failed the same test, but in the function snd_interval_refine_min().
    I haven't developed with ALSA yet, so I don't know the ropes
completely. Anyone have any idea what's happening here? I checked
the online docs and couldn't find any references regarding
"interval"s. Is this a timing issue?


-- Peter Heatwole
"Murphy was just a well known pessimist."



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

Re: SPDIF output finally working properly with CS4630

[Peter Heatwole]

On 2002.07.23 21:28 Benny Sjostrand wrote:
>> [peter@porky als]$ aplay footsteps.wav Playing WAVE 'footsteps.wav' :
>> Signed 16 bit Little Endian, Rate 44100 Hz, Mono
>> aplay: interval_inline.h:65: snd_interval_min: Assertion 
>> `!snd_interval_empty(i)' failed.
>> Aborted...

    This is odd. I was going to play with the driver some more this
morning, and when I tried to play a sound... it played! I didn't change
anything since I last tried it, except that I had my computer turned off
overnight. Perhaps it was the cold boot that effected it. Anyway, now it
plays, but I don't get IEC958 output, and the analog out was very
"tinny". I reloaded the module, and now the sound from analog out is
fine.
    I'll keep playing with it.

-- Peter Heatwole
"Murphy was just a well known pessimist."



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

Re: SPDIF output finally working properly with CS4630

[Benny Sjostrand]

>    This is odd. I was going to play with the driver some more this
> morning, and when I tried to play a sound... it played! I didn't change
> anything since I last tried it, except that I had my computer turned off
> overnight. Perhaps it was the cold boot that effected it. Anyway, now it
> plays, but I don't get IEC958 output, and the analog out was very
> "tinny". I reloaded the module, and now the sound from analog out is
> fine.
>    I'll keep playing with it.

About the IEC958, remember to unmute it via the ALSA mixer, it does not 
apear
with the Gnome Mixer, or any other OSS mixer.

When you are playing the .WAV file take a look in /proc/asound/card0/dsp_scb
and check after the line "0bc0 SPDIFOSCB:", should be something like:
0bc0 SPDIFOSCB:
80002001 000000b0 00000000 00000000
00000000 00000086 1a4afffc 00000001
00000000 00000600 0bcd020f 00000040
000020ff 0005804c 00010108 deadc0ed

The first DWORD (80002001) monitors the SPDIF output status register, it 
should be different
than 0 if SPDIF output is active.

Then you can check the /proc/asound/card0/dsp_sample, should look 
something like:
PCMREADER:
0600 0750FD6A 0763FD6C 0778FD6D 0781FD77
0610 0787FD8F 0797FDA3 07A4FDAD 07A1FDB9
0620 079CFDCB 07A0FDE0 07A5FDFB 07A7FE1A
MIX_SAMPLE_BUF1:
1400 F95E0394 F94A039D F93F0395 F93A038B
1410 F934038A F92B038F F923039A F92703AB
1420 F93203C0 F93503DD F93303FC F9390415

1780 00000000 00000000 00000000 00000000
1790 00000000 00000000 00000000 00000000
17A0 00000000 00000000 00000000 00000000
17B0 00000000 00000000 00000000 00000000
17C0 00000000 00000000 00000000 00000000
17D0 00000000 00000000 00000000 00000000
17E0 00000000 00000000 00000000 00000000
17F0 00000000 00000000 00000000 00000000
SPDIFO_BUFFER:
1800 010EFF9F 0105FF9D 00F3FFAE 00DFFFCA
1810 00CEFFE9 00BF0015 00A90056 009000A7
1820 007C00FD 00680158 004D01BB 002B0222
1830 00080281 FFE402D7 FFB90325 FF8C0367
...
18D0 FBFE0379 FBE30360 FBC50351 FBA6034B
18E0 FB880345 FB700341 FB610347 FB500355
18F0 FB320365 FB110370 FAF50378 FADC037D
1900 FAC1037D FAA40377 FA8D0369 FA790353
OUTPUT_SNOOP:
1200 00000000 00000000 00000000 00000000
1210 00000000 00000000 00000000 00000000

The SPDIFO_BUFFER part the values should be different than 0,
and there is a stream.

/Benny




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

Re: SPDIF output finally working properly with CS4630

[Peter Heatwole]

On 2002.07.24 11:41 Benny Sjostrand wrote:
> About the IEC958, remember to unmute it via the ALSA mixer, it does not 
> apear
> with the Gnome Mixer, or any other OSS mixer.
> 
> When you are playing the .WAV file take a look in 
> /proc/asound/card0/dsp_scb
> and check after the line "0bc0 SPDIFOSCB:", should be something like:


    It's different than your included output, but it's not zero's. And yes,
I unmuted both entries "IEC958" and "IEC 958" with alsamixer.


-- Peter Heatwole
"Murphy was just a well known pessimist."



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

Re: SPDIF output finally working properly with CS4630

[Benny Sjostrand]

>    It's different than your included output, but it's not zero's. And 
> yes,
> I unmuted both entries "IEC958" and "IEC 958" with alsamixer.

The "IEC958" controll is probably there course my incorrect changes in 
ac97_codec.c that should not
be there. The "ICE 958 output" control is the one from cs46xx_lib.c.
Then how does the /proc/asound/card0/dsp_sample looks like when you
playing a .WAV file ?

If your IEC958 is optical and you see a red light it's a good sign.

/Benny



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

Re: SPDIF output finally working properly with CS4630

[Peter Heatwole]

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

On 2002.07.24 12:59 Benny Sjostrand wrote:
> The "IEC958" controll is probably there course my incorrect changes in 
> ac97_codec.c that should not
> be there. The "ICE 958 output" control is the one from cs46xx_lib.c.
> Then how does the /proc/asound/card0/dsp_sample looks like when you
> playing a .WAV file ?
> 
> If your IEC958 is optical and you see a red light it's a good sign.

    The IEC958 control is supposed to be there because of the CS4297A 
codec.
Your changes only involved the CS4297.
    My IEC958 is coaxial, and I'm using a set of Cambridge SoundWorks
DTT2500 Digital speakers. I don't know of any other way to check if the
card is sending a signal or not.
    I've attached a few files that may help. I just noticed some module
errors that may be the cause of my problems.

messages.txt:  /var/log/messages after insmodding my module


-- Peter Heatwole
"Murphy was just a well known pessimist."


[-- Attachment #2: dsp_parameter --]
[-- Type: text/plain, Size: 4091 bytes --]


nullSCB:
0000 00000000 00000000 00000000 00000000 
0004 00000000 00000000 00000000 00000000 
0008 00000000 00000000 00000169 00000000 
000C FE980000 00000000 00000000 00000000 

TimingMasterSCBInst:
0010 00000000 00000000 00000000 00000000 
0014 00000000 00000000 00000000 00000000 
0018 00000000 00200000 00008010 00000000 
001C 00090001 80000001 00000001 00060000 

CodecOutSCB:
0020 00000000 00000000 00000000 00000000 
0024 00000000 00000000 00000000 00000000 
0028 00000000 00900080 00000179 00000000 
002C 00000000 00000010 00800000 00900000 

PCMreaderSCB:
0030 F2C0400F 00000200 07B84900 00010600 
0034 00000000 00000000 00000000 00000000 
0038 00000000 00000000 00000169 330300C2 
003C 06200000 00000000 80008000 80008000 

WriteBackSCB:
0040 3FC0000F 00000301 00010400 00000000 
0044 00000000 00000000 00000000 00000000 
0048 00000000 00B00000 00D0806D 330480C3 
004C 04800000 00000003 00800003 0000FFFF 
0050 00000000 00000000 00000000 00000000 
0054 00000000 00000000 00000000 00000000 
0058 00000000 00000000 00000000 00000000 
005C 00000000 00000000 00000000 00000000 
0060 00000000 00000000 00000000 00000000 
0064 00000000 00000000 00000000 00000000 
0068 00000000 00000000 00000000 00000000 
006C 00000000 00000000 00000000 00000000 

SPOSCB:
0070 066A0BA0 06350070 00000BAD 0BAD0BAD 
0074 00000000 0000DEAD 00000600 00000000 
0078 0000DEAD 00000000 00010000 DEADDEAD 
007C 0BAD0BAD 0BAD0BAD 0BAD0BAD 00000000 

CodecInSCB:
0080 00000000 00000000 00000000 00000000 
0084 00000000 00000000 00000000 00000000 
0088 00000000 00000130 0000804F 000000C3 
008C 05780000 00A00010 00000000 80008000 

MasterMixSCB:
0090 00000000 00000000 00001478 00000000 
0094 00000000 00000000 00000000 00000000 
0098 00000080 00A00000 0000809A 000000C3 
009C 14F80000 00000000 80008000 80007FFF 

SRCtaskSCBInst:
00A0 0029001B 00015555 000000C0 000107B8 
00A4 00C80028 000000C2 06A00000 01FFFFCC 
00A8 06840080 00300000 000080BB 000000C9 
00AC 07B80000 03ACCCCC 80008000 80007FFF 

VariDecimateSCB:
00B0 00C80028 00005555 00000000 00000780 
00B4 00C80028 000000C5 FFEAAAAB 00000000 
00B8 02400080 00C00000 00008197 000000C9 
00BC 07800000 18000000 80008000 FFFFFFFF 

PCMserialInSCB:
00C0 00000000 00000000 00000000 00000000 
00C4 00000000 00000000 00000000 00000000 
00C8 00000000 00000000 0000805E 000000C1 
00CC 00000000 00800000 80008000 80008000 
00D0 00005555 0000FFFF 00000000 00000000 
00D4 00000000 00000000 00000000 00000000 
00D8 00000000 00000000 00000000 00000000 
00DC 00000000 00000000 00000000 00000000 

AsynchFGTxSCBInst:
00E0 07FFF800 01100610 0BC00000 00000000 
00E4 00000000 2AAB0000 00000000 00000000 
00E8 00000000 00A00000 00E4022B 000000C6 
00EC 18140000 18000000 80008000 80008000 

AsynchFGRxSCBInst:
00F0 00FFFF00 03800380 0BB00000 00000000 
00F4 00000000 00000000 00000000 00000000 
00F8 00000000 00000000 00F00252 000000C3 
00FC 0E000000 00000000 80008000 FFFFFFFF 
0100 00000000 00000000 00000000 00000000 
0104 00000000 00000000 00000000 00000000 
0108 00000000 00000000 00000000 00000000 
010C 00000000 00000000 00000000 00000000 

OutputSnoopSCB:
0110 00000000 00000000 00000000 00000000 
0114 00000000 00000000 00000000 00000000 
0118 00000000 00000000 0000026F 000000C3 
011C 12000000 00000000 00000000 00200000 
0120 00000000 00000000 00000000 00000000 
0124 00000000 00000000 00000000 00000000 
0128 00000000 00000000 00000000 00000000 
012C 00000000 00000000 00000000 00000000 

SPIOWriteSCB:
0130 804D804D 00000000 00000000 00000000 
0134 00000000 00000000 00000000 00000000 
0138 00000000 00000000 00000194 00000000 
013C 00000000 00000000 00000000 00000000 
0140 00000000 00000000 00000000 00000000 
0144 00000000 00000000 00000000 00000000 
0148 00000000 00000000 00000000 00000000 
014C 00000000 00000000 00000000 00000000 
0150 00000000 00000000 00000000 00000000 
0154 00000000 00000000 00000000 00000000 
0158 00000000 00000000 00000000 00000000 
015C 00000000 00000000 00000000 00000000 
0160 00000000 00000000 00000000 00000000 
0164 00000000 00000000 00000000 00000000 
0168 00000000 00000000 00000000 00000000 
016C 00000000 00000000 00000000 

[-- Attachment #3: dsp_sample --]
[-- Type: text/plain, Size: 1326 bytes --]

PCMREADER:
0600 ED42F99C EE6EF940 EFB0F8EF F0F6F8A9 
0610 F236F86E F372F83F F4AAF818 F5DDF7F5 
0620 F70DF7D1 F83AF7A6 F969F778 FAA3F742 
MIX_SAMPLE_BUF1:
1400 FF0BF666 FE8DF5C0 FE00F526 FD60F499 
1410 FCBFF421 FC1CF3BF FB76F36F FAD7F334 
1420 FA45F314 F9C4F30B F94FF319 F8EAF33E 

1780 00000000 00000000 00000000 00000000 
1790 00000000 00000000 00000000 00000000 
17A0 00000000 00000000 00000000 00000000 
17B0 00000000 00000000 00000000 00000000 
17C0 00000000 00000000 00000000 00000000 
17D0 00000000 00000000 00000000 00000000 
17E0 00000000 00000000 00000000 00000000 
17F0 00000000 00000000 00000000 00000000 
SPDIFO_BUFFER:
1800 00000000 00000000 00000000 00000000 
1810 00000000 00000000 00000000 00000000 
1820 00000000 00000000 00000000 00000000 
1830 00000000 00000000 00000000 00000000 
...
18D0 00000000 00000000 00000000 00000000 
18E0 00000000 00000000 00000000 00000000 
18F0 00000000 00000000 00000000 00000000 
1900 00000000 00000000 00000000 00000000 
OUTPUT_SNOOP:
1200 00000000 00000000 00000000 00000000 
1210 00000000 00000000 00000000 00000000 
1220 00000000 00000000 00000000 00000000 
1230 00000000 00000000 00000000 00000000 
...
12D0 00000000 00000000 00000000 00000000 
12E0 00000000 00000000 00000000 00000000 
12F0 00000000 00000000 00000000 00000000 
1300 00000000 00000000 00000000 00000000 

[-- Attachment #4: dsp_scb --]
[-- Type: text/plain, Size: 2864 bytes --]

SCB's:

0000 nullSCB:
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000169 00000000 
fe980000 00000000 00000000 00000000 
0010 TimingMasterSCBInst:
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00200000 00008010 00000000 
00070001 80000001 00000001 00060000 
0020 CodecOutSCB:
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00900080 00000179 00000000 
00000000 00000010 00800000 00900000 
0030 PCMreaderSCB:
f2c0400f 00000200 07b84980 00010600 
00000000 00000000 00000000 00000000 
00000000 00000000 00000169 330300c2 
06480000 00000000 80008000 80008000 
0040 WriteBackSCB:
3fc0000f 00000301 00010400 00000000 
00000000 00000000 00000000 00000000 
00000000 00b00000 00d0806d 330480c3 
04800000 00000003 00800003 0000ffff 
0080 CodecInSCB:
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000130 0000804f 000000c3 
05000000 00a00010 00000000 80008000 
0090 MasterMixSCB:
00000000 00000000 00001400 00000000 
00000000 00000000 00000000 00000000 
00000080 00a00000 0000809a 000000c3 
14800000 00000000 80008000 80007fff 
00a0 SRCtaskSCBInst:
00210020 00025555 000000c0 000107a0 
00c80028 000000c2 06b80000 01ccccac 
06a00080 00300000 000080bb 000000c9 
07b80000 03accccc 80008000 80007fff 
00b0 VariDecimateSCB:
00c80028 00005555 00000000 00000780 
00c80028 000000c5 ffeaaaab 00000000 
02400080 00c00000 00008197 000000c9 
07800000 18000000 80008000 ffffffff 
00c0 PCMserialInSCB:
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 0000805e 000000c1 
00000000 00800000 80008000 80008000 
00e0 AsynchFGTxSCBInst:
07fff800 01100610 0bc00000 00000000 
00000000 2aab0000 00000000 00000000 
00000000 00a00000 00e4022b 000000c6 
18140000 18000000 80008000 80008000 
00f0 AsynchFGRxSCBInst:
00ffff00 03800380 0bb00000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00f00252 000000c3 
0e000000 00000000 80008000 ffffffff 
0110 OutputSnoopSCB:
00000000 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 0000026f 000000c3 
12000000 00000000 00000000 00200000 
0130 SPIOWriteSCB:
804d804d 00000000 00000000 00000000 
00000000 00000000 00000000 00000000 
00000000 00000000 00000194 00000000 
00000000 00000000 00000000 00000000 
0bc0 SPDIFOSCB:
00000000 000000b0 00000000 00000000 
00000000 00000086 1820fffc 00000000 
00000000 00000600 0bcd020f 00000040 
000020ff 0000804c 00010108 deadc0ed 
0bb0 SPDIFISCB:
deadc0ed 00000000 00000000 0fa00001 
deadc0ed dead000c deadc0ed 0baddead 
deadc0ed 00000bc0 0bbd01d7 00000086 
0e00fffc 00008048 000101f0 00000008 
0ba0 AsynCodecInputSCB:
deadc0ed 00000000 00000000 0fa00001 
00010118 00000086 0a00fffc 00030000 
deadc0ed 00000bb0 0bad01a1 00000086 
0a000000 00008042 00010100 00000000 

[-- Attachment #5: messages.txt --]
[-- Type: text/plain, Size: 7875 bytes --]


Jul 24 13:23:08 porky kernel: PCI: Found IRQ 11 for device 00:09.0
Jul 24 13:23:08 porky kernel: vendorID 00005053 subsystemID 00003357
Jul 24 13:23:08 porky kernel: hack for Voyetra enabled
Jul 24 13:23:09 porky kernel: dsp_spos: loading module cwc4630 into DSP
Jul 24 13:23:09 porky kernel: dsp_spos: clearing parameter area
Jul 24 13:23:09 porky kernel: snd_cs46xx_clear_BA1 bank 00
Jul 24 13:23:09 porky kernel: dsp_spos: downloading parameter data to chip (00000000-00000200)
Jul 24 13:23:09 porky kernel: snd_cs46xx_download bank 00
Jul 24 13:23:09 porky kernel: dsp_spos: clearing sample area
Jul 24 13:23:09 porky kernel: snd_cs46xx_clear_BA1 bank 01
Jul 24 13:23:09 porky kernel: dsp_spos: module got no sample segment
Jul 24 13:23:09 porky kernel: dsp_spos: clearing code area
Jul 24 13:23:09 porky kernel: snd_cs46xx_clear_BA1 bank 02
Jul 24 13:23:09 porky kernel: dsp_spos: downloading code to chip (00020000-00020ca0)
Jul 24 13:23:09 porky kernel: dsp_spos: 0 instructions reallocated
Jul 24 13:23:09 porky kernel: snd_cs46xx_download bank 02
Jul 24 13:23:09 porky kernel: dsp_spos: loading module cwcasync into DSP
Jul 24 13:23:09 porky kernel: dsp_spos: module got no parameter segment
Jul 24 13:23:09 porky kernel: dsp_spos: module got no sample segment
Jul 24 13:23:09 porky kernel: dsp_spos: downloading code to chip (00020ca0-00021378)
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01400:02731 addr 8000
Jul 24 13:23:09 porky kernel: handle_wideop[1]: ROM symbol not reallocated
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01400:02731 addr 8000
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01000:60630 addr 000c
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 0100d:00630 addr 01a0
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01000:20630 addr 0004
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 0100c:c0630 addr 0198
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01400:42730 addr 8008
Jul 24 13:23:09 porky kernel: handle_wideop[1]: ROM symbol not reallocated
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01400:42730 addr 8008
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01000:f0630 addr 001e
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 0100d:90630 addr 01b2
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01000:e00f2 addr 001c
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 0100d:800f2 addr 01b0
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01001:e8030 addr 003d
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 0100e:88030 addr 01d1
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01001:82630 addr 0030
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 0100e:22630 addr 01c4
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01001:504a0 addr 002a
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 0100d:f04a0 addr 01be
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01001:e8630 addr 003d
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 0100e:88630 addr 01d1
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01001:d84a0 addr 003b
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 0100e:784a0 addr 01cf
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01002:b8630 addr 0057
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 0100f:58630 addr 01eb
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01002:ac0f2 addr 0055
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 0100f:4c0f2 addr 01e9
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01003:ac030 addr 0075
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01010:4c030 addr 0209
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01003:884a0 addr 0071
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01010:284a0 addr 0205
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01003:706b0 addr 006e
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01010:106b0 addr 0202
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01003:78730 addr 006f
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01010:18730 addr 0203
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01004:8c030 addr 0091
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01011:2c030 addr 0225
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01004:704a0 addr 008e
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01011:104a0 addr 0222
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01400:02731 addr 8000
Jul 24 13:23:09 porky kernel: handle_wideop[1]: ROM symbol not reallocated
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01400:02731 addr 8000
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01005:64630 addr 00ac
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01012:04630 addr 0240
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01005:746b0 addr 00ae
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01012:146b0 addr 0242
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01400:40630 addr 8008
Jul 24 13:23:09 porky kernel: handle_wideop[1]: ROM symbol not reallocated
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01400:40630 addr 8008
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01005:d86a0 addr 00bb
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01012:786a0 addr 024f
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01400:42730 addr 8008
Jul 24 13:23:09 porky kernel: handle_wideop[1]: ROM symbol not reallocated
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01400:42730 addr 8008
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01006:60630 addr 00cc
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01013:00630 addr 0260
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01400:586b0 addr 800b
Jul 24 13:23:09 porky kernel: handle_wideop[1]: ROM symbol not reallocated
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01400:586b0 addr 800b
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01400:500b0 addr 800a
Jul 24 13:23:09 porky kernel: handle_wideop[1]: ROM symbol not reallocated
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01400:500b0 addr 800a
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01400:40730 addr 8008
Jul 24 13:23:09 porky kernel: handle_wideop[1]: ROM symbol not reallocated
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01400:40730 addr 8008
Jul 24 13:23:09 porky kernel: dsp_spos: 29 instructions reallocated
Jul 24 13:23:09 porky kernel: snd_cs46xx_download bank 02
Jul 24 13:23:09 porky kernel: dsp_spos: loading module cwcsnoop into DSP
Jul 24 13:23:09 porky kernel: dsp_spos: module got no parameter segment
Jul 24 13:23:09 porky kernel: dsp_spos: module got no sample segment
Jul 24 13:23:09 porky kernel: dsp_spos: downloading code to chip (00021378-00021470)
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01028:80630 addr 0510
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01013:f8630 addr 027f
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01028:a83a0 addr 0515
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01014:203a0 addr 0284
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01028:d8730 addr 051b
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01014:50730 addr 028a
Jul 24 13:23:09 porky kernel: dsp_spos: 3 instructions reallocated
Jul 24 13:23:09 porky kernel: snd_cs46xx_download bank 02
Jul 24 13:23:09 porky kernel: dsp_spos: loading module cwcbinhack into DSP
Jul 24 13:23:09 porky kernel: dsp_spos: module got no parameter segment
Jul 24 13:23:09 porky kernel: dsp_spos: module got no sample segment
Jul 24 13:23:09 porky kernel: dsp_spos: downloading code to chip (00021470-00021570)
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01016:b8630 addr 02d7
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01014:e8630 addr 029d
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01016:e03a0 addr 02dc
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01015:103a0 addr 02a2
Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01017:10730 addr 02e2
Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01015:40730 addr 02a8
Jul 24 13:23:09 porky kernel: dsp_spos: 3 instructions reallocated
Jul 24 13:23:09 porky kernel: snd_cs46xx_download bank 02
Jul 24 13:23:09 porky kernel: MasterMixSCB

Re: SPDIF output finally working properly with CS4630

[Benny Sjostrand]

>    The IEC958 control is supposed to be there because of the CS4297A 
> codec.
> Your changes only involved the CS4297.
>    My IEC958 is coaxial, and I'm using a set of Cambridge SoundWorks
> DTT2500 Digital speakers. I don't know of any other way to check if 
> the card is sending a signal or not. 

Well, if you have access to a oscilloscope that can be programed to view 
the differential result
of the signals then probably you can proably view the digital data.
But i've never tested to do this, and don't have any access to a 
oscilloscope at home ...

>
>    I've attached a few files that may help. I just noticed some module
> errors that may be the cause of my problems.


Then, do you know if your IEC958 is connected to CS4297A or CS4630 ??
If it is connected to the CS4297A then this patch will not provide any 
output
on that IEC958 port.
.

>WriteBackSCB:
>0040 3FC0000F 00000301 00010400 00000000 
>0044 00000000 00000000 00000000 00000000 
>0048 00000000 00B00000 00D0806D 330480C3 
>004C 04800000 00000003 00800003 0000FFFF 
>0050 00000000 00000000 00000000 00000000 
>0054 00000000 00000000 00000000 00000000 
>0058 00000000 00000000 00000000 00000000 
>005C 00000000 00000000 00000000 00000000 
>0060 00000000 00000000 00000000 00000000 
>0064 00000000 00000000 00000000 00000000 
>0068 00000000 00000000 00000000 00000000 
>006C 00000000 00000000 00000000 00000000 
>
This dump should not be that long!
Did you change anything in the code ? the SCB block
has always a fixed size of 16 Dwords. A new SCB block will
start on 0x0050.

>
>MasterMixSCB:
>0090 00000000 00000000 00001478 00000000 
>0094 00000000 00000000 00000000 00000000 
>0098 00000080 00A00000 0000809A 000000C3 
>009C 14F80000 00000000 80008000 80007FFF 
>
The 9th Dword in SCB is the sub_list_ptr which points
to the SCB's child SCB. Which is in this case is 00A0
which points to the SRCTaskSCB (sample rate converter).
When SPDIF output is muted the MasterMixSCB sub_list_ptr
is 00A0 -> SRCTaskSCB, and when SPDIF output is unmuted
sub_list_ptr is 0x00E0 AsynchFGTxSCB.
In the moment of this dump the SPDIF seems to be muted.

>
>PCMREADER:
>0600 ED42F99C EE6EF940 EFB0F8EF F0F6F8A9 
>0610 F236F86E F372F83F F4AAF818 F5DDF7F5 
>0620 F70DF7D1 F83AF7A6 F969F778 FAA3F742 
>MIX_SAMPLE_BUF1:
>1400 FF0BF666 FE8DF5C0 FE00F526 FD60F499 
>1410 FCBFF421 FC1CF3BF FB76F36F FAD7F334 
>1420 FA45F314 F9C4F30B F94FF319 F8EAF33E 
>
>1780 00000000 00000000 00000000 00000000 
>1790 00000000 00000000 00000000 00000000 
>17A0 00000000 00000000 00000000 00000000 
>17B0 00000000 00000000 00000000 00000000 
>17C0 00000000 00000000 00000000 00000000 
>17D0 00000000 00000000 00000000 00000000 
>17E0 00000000 00000000 00000000 00000000 
>17F0 00000000 00000000 00000000 00000000 
>SPDIFO_BUFFER:
>1800 00000000 00000000 00000000 00000000 
>1810 00000000 00000000 00000000 00000000 
>1820 00000000 00000000 00000000 00000000 
>1830 00000000 00000000 00000000 00000000 
>...
>18D0 00000000 00000000 00000000 00000000 
>18E0 00000000 00000000 00000000 00000000 
>18F0 00000000 00000000 00000000 00000000 
>1900 00000000 00000000 00000000 00000000 
>OUTPUT_SNOOP:
>1200 00000000 00000000 00000000 00000000 
>1210 00000000 00000000 00000000 00000000 
>1220 00000000 00000000 00000000 00000000 
>1230 00000000 00000000 00000000 00000000 
>...
>12D0 00000000 00000000 00000000 00000000 
>12E0 00000000 00000000 00000000 00000000 
>12F0 00000000 00000000 00000000 00000000 
>1300 00000000 00000000 00000000 00000000 
>
As the SPDIFO_BUFFER is empty nothing is going
out to the SPDIF output.

>
>0090 MasterMixSCB:
>00000000 00000000 00001400 00000000 
>00000000 00000000 00000000 00000000 
>00000080 00a00000 0000809a 000000c3 
>14800000 00000000 80008000 80007fff 
>
Here SPDIF still muted.


>
>0130 SPIOWriteSCB:
>804d804d 00000000 00000000 00000000 
>00000000 00000000 00000000 00000000 
>00000000 00000000 00000194 00000000 
>00000000 00000000 00000000 00000000 
>
Last IO wroten by cs46xx_poke_via_dsp(...) was address 0x804d, and value 0x0
the 0x804d is the SP SPDOUT_CONTROL register, value 0 disables SPDIF.
Probably cs46xx_dsp_disable_spdif_in() was invoked, is invoked
at end of snd_cs46xx_chip_init(...) when module is initialized..

>
>0bc0 SPDIFOSCB:
>00000000 000000b0 00000000 00000000 
>00000000 00000086 1820fffc 00000000 
>00000000 00000600 0bcd020f 00000040 
>000020ff 0000804c 00010108 deadc0ed 
>
First dword 0, SPDIF output inactive.

>Jul 24 13:23:09 porky kernel: dsp_spos: downloading code to chip (00021470-00021570)
>Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01016:b8630 addr 02d7
>Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01014:e8630 addr 029d
>Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01016:e03a0 addr 02dc
>Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01015:103a0 addr 02a2
>Jul 24 13:23:09 porky kernel: handle_wideop[1]: 01017:10730 addr 02e2
>Jul 24 13:23:09 porky kernel: handle_wideop:[2] 01015:40730 addr 02a8
>Jul 24 13:23:09 porky kernel: dsp_spos: 3 instructions reallocated
>Jul 24 13:23:09 porky kernel: snd_cs46xx_download bank 02
>Jul 24 13:23:09 porky kernel: MasterMixSCB
>
Well, that's what i can interpret from this outputs.

Everything look basically OK.
Seems like you have loaded the module successfully and have not started
playing yet.

/Benny




-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

Re: SPDIF output finally working properly with CS4630

[Peter Heatwole]

On 2002.07.24 14:53 Benny Sjostrand wrote:
> Well, if you have access to a oscilloscope that can be programed to view 
> the differential result
> of the signals then probably you can proably view the digital data.
> But i've never tested to do this, and don't have any access to a 
> oscilloscope at home ...

    Neither do I. =)

> Then, do you know if your IEC958 is connected to CS4297A or CS4630 ??
> If it is connected to the CS4297A then this patch will not provide any 
> output on that IEC958 port.

    Looking at the datasheets and schematics, it looks like the CS4630 uses
AC97 codecs to actually process and output it's iec958 frames. I could
easily be wrong, but the schematics for the CS4630-CM don't show the
circuitry necessary to power and control an iec958 line. It shows a pin,
which I assume links to the codec (in my case, a CS4297A). Is there
a datasheet that could show me what you mean?

[...]
> This dump should not be that long!
> Did you change anything in the code ? the SCB block
> has always a fixed size of 16 Dwords. A new SCB block will
> start on 0x0050.

    No, I haven't changed a thing.

> Well, that's what i can interpret from this outputs.
> 
> Everything look basically OK.
> Seems like you have loaded the module successfully and have not started
> playing yet.

    Strange. Well, if it _were_ the case that my card is using a CS4297A 
for
digital output, do you think that would cause this?


-- Peter Heatwole
"Murphy was just a well known pessimist."



-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

Re: SPDIF output finally working properly with CS4630

[Peter Heatwole]

On 2002.07.24 16:37 Peter Heatwole wrote:
>    Looking at the datasheets and schematics, it looks like the CS4630 
> uses
> AC97 codecs to actually process and output it's iec958 frames. I could
> easily be wrong, but the schematics for the CS4630-CM don't show the
> circuitry necessary to power and control an iec958 line. It shows a pin,
> which I assume links to the codec (in my case, a CS4297A). Is there
> a datasheet that could show me what you mean?


    Hmm. Seems like I'm wrong. I just remembered you mentioned that the
Game Theatre only has 2 CS4294 codecs, which suggests that the CS4630
does indeed have it's own iec958 output pin. I wish I understood schematics
better. The one I was looking at must have just generalized and I took it
literally.

-- Peter Heatwole
"Murphy was just a well known pessimist."


-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

Re: SPDIF output finally working properly with CS4630

[Peter Heatwole]

On 2002.07.24 14:53 Benny Sjostrand wrote:
>> MasterMixSCB:
>> 0090 00000000 00000000 00001478 00000000 0094 00000000 00000000 
>> 00000000 00000000 0098 00000080 00A00000 0000809A 000000C3 009C 
>> 14F80000 00000000 80008000 80007FFF
> The 9th Dword in SCB is the sub_list_ptr which points
> to the SCB's child SCB. Which is in this case is 00A0
> which points to the SRCTaskSCB (sample rate converter).
> When SPDIF output is muted the MasterMixSCB sub_list_ptr
> is 00A0 -> SRCTaskSCB, and when SPDIF output is unmuted
> sub_list_ptr is 0x00E0 AsynchFGTxSCB.
> In the moment of this dump the SPDIF seems to be muted.

    I can watch what you're saying as I mute and unmute "IEC 958" in
alsamixer. Muted, the 9th dword is 00a0, unmuted it's 00e0. Side question:
you referenced AsynchFGTxSCB. What's the FGT acronym stand for?)


>> 0bc0 SPDIFOSCB:
>> 00000000 000000b0 00000000 00000000 00000000 00000086 1820fffc 00000000 
>> 00000000 00000600 0bcd020f 00000040 000020ff 0000804c 00010108 deadc0ed
> First dword 0, SPDIF output inactive.

    Here's a strange one. With "IEC 958" muted, I view dsp_scb, and the
first dword of SPDIFOSCB is 00000000. I unmute "IEC 958", and I can watch
the first dword of SPDIFOSCB change each time I view dsp_scb. Here's a list
of each individual number I get (duplicates have been removed):

80005001
80001001
80000001
80002001
00001001
80003001
80006001
00006001
00003001
00004001
80003001
80004001
00000001
00007001
80005001
00005001
80007001
00002001
00005001

    I tried this with and without sounds playing (though I still can't hear
them). Do you have any information regarding what each bit stands for in
the first dword of SPDIFOSCB? (if you do, could you point me to where you
obtained this information so I can try to educate myself?)  I'm writing
this because it seems strange; I don't understand why the status bits would
keep changing for no (apparent) reason.


-- Peter Heatwole
"Murphy was just a well known pessimist."



-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

Re: SPDIF output finally working properly with CS4630

[Benny Sjostrand]

>    I can watch what you're saying as I mute and unmute "IEC 958" in
> alsamixer. Muted, the 9th dword is 00a0, unmuted it's 00e0. Side 
> question:
> you referenced AsynchFGTxSCB. What's the FGT acronym stand for?) 


I believe it stands for "Asynchronous Foreground transfer", it's the task
in DSP that's responsible to tranfer samples from Foreground to
Hyperforeground.

>
>    Here's a strange one. With "IEC 958" muted, I view dsp_scb, and the
> first dword of SPDIFOSCB is 00000000. I unmute "IEC 958", and I can watch
> the first dword of SPDIFOSCB change each time I view dsp_scb. Here's a 
> list
> of each individual number I get (duplicates have been removed):

The SPDIFOSCB task runs in Hyperforeground on DSP, it's responsible
to transfer samples to the HW FIFO.

>
> 80005001
> 80001001
> 80000001
> 80002001
> 00001001
> 80003001
> 80006001
> 00006001
> 00003001
> 00004001
> 80003001
> 80004001
> 00000001
> 00007001
> 80005001
> 00005001
> 80007001
> 00002001
> 00005001

If you want to find out more details about this, the CS4630 design spec.
Page 228. the SPDOUT_STATUS register.

>
>    I tried this with and without sounds playing (though I still can't 
> hear
> them). Do you have any information regarding what each bit stands for in
> the first dword of SPDIFOSCB? (if you do, could you point me to where you
> obtained this information so I can try to educate myself?)  I'm writing
> this because it seems strange; I don't understand why the status bits 
> would
> keep changing for no (apparent) reason.

We dont have any documentaion about the SCB's. The references I got are 
DSP assembler
sources of some tasks some examples about how to setup the SCB's.
Some hints from Cirrus, and analyzing the assembler sources (and 
binaries) is where i've been
token this conlusions, what probes that i'm right is that it seems to 
work, but I can be wrong in
some points.

Hopefully the code I wrote helps uncovers some internals of the DSP, 
before you
start reading the assembler sources by "the hard way" take a look at 
alsa-kernel/include/cs46xx_dsp_scb_types.h
and alsa-kernel/include/cs46xx_dsp_task_types.h first.

/Benny




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

Re: SPDIF output finally working properly with CS4630

[Takashi Iwai]

Hi Benny,

At Tue, 23 Jul 2002 22:33:38 +0200,
Benny Sjostrand wrote:
> 
> Hi!
> 
> After a lot fustrated hacking nights and days, finally (at least) I 
> manage to get a properly sound out from SPDIF interface on my Hercules 
> Game Theater XP card, at least "so far as i can hear". The sound is no 
> longer distorcionated and SPDIF is now integrated with the ALSA mixer 
> (muted by default).
 
great!  i'll take a look, too.


> About other missing basic feutures, SPDIF input, 4 channels, multi PCM 
> etc., well, I'm working on that, we see what I can do, at least there is 
> a hope ...
 
yeah, 4 channels would be really nice.

> The code is still very dirty, noisy, well, I know that it needs a lot of 
> cleanup.
> 
> My new current snapshots:
> http://www.cucumelo.org/~gorm/alsa-driver-0.9.0rc2-bs20020723.tar.gz
> http://www.cucumelo.org/~gorm/ospparser.tar.gz
 
ossparser could be put into alsa-tools package.

> Please, test it and give some feedback, maybe there are things that was 
> working before
> and are now broken., etc ...
> 
> but,
> NOTE the code is very EXPERIMENTAL and may be very UNSTABLE for the moment.


Takashi


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