GX1-CS5530 sound problem !!!

Hi Laurent, this is my configuration, which works fine:

Kernel-configuration: CONFIG_SOUND=y CONFIG_SOUND_OSS=y CONFIG_SOUND_DMAP=y // (I had no problems without this option) CONFIG_SOUND_SB=y // 100% SB compatible

Because I don't use kernel modules I need in the lilo.conf: append="sb=0x220,5,1,5"

Don't forget to enable the "soundcard" in the BIOS and set the appropriate IRQ and IO-address...

Best regards, Juergen

Thanks !! I try it s soon I can

Laurent

"Jürgen Querengässer" a écrit dans le message de news: snipped-for-privacy@uni-berl>

I try it and it works fine But in one case, I have a message "Sound: DMA timed out possible IRQ/DRQ conflict? " and it does'nt work I reboot it but I always have this problem... I have to power off the card so that it works fine again ...

"Jürgen Querengässer" a écrit dans le message de news: snipped-for-privacy@uni-berl>

Google gives a lot of hints :-)

For example I found this (from Hannu Savolainen):

-------------------------------------------------

- If you hear some _looping_ sound before the timeout, you have an IRQ conflict.

- If you hear no sound at all, you have a DMA conflict.

- If everything works OK for some time but sound stops after some SCSI activity, you have just bad luck. PAS16 and AHA1542 are known to be incompatible. There is just a minor possibility that adjusting the bus on/off times of AHA solves this problem. Does anybody have experience on this?

-------------------------------------------------

I would try to detect which device causes the IRQ or DMA-Request conflict (/proc/interrupts, /proc/dma) and then to assign the soundcard (or the conflict-device) an other IRQ resp. DMA (in the BIOS and lilo.conf)

Best regards, Juergen

The PAS16 codes in the sound driver is strange. We removed them and the SB driver works much better. We have not seen any PAS16 board/chip anyway.

We found that if you are running heavy sound I/O, i.e. mp3 and video at the same time, the geode interrupt stack gets confused.

...

The conflict is inside the geode companion chip, there is nothing you can do about it.

Our solution is to put it in graphic mode (even for simple text display) for mp3. X appears to have less latency than the Geode's Virtual VGA system. However, it does take up much more system memory. On the plus side, system memory seems to be faster than the bios memory anyway.

Hi 'Tech Support for IDE-CF',

I'm interested in how did you find this.

I would like to know how I can provoke such behaviour. My app. also needs much CPU time and has to serve much interrupts and does video output. (Video uses the VESA-framebuffer device and afaik it doesn't need an interrupt. Furthermore the video memory is shared with the system memory (also in the virtual VGA mode [I think]) and should not slower or faster than X (unless X uses hardware acceleration; but this is possible in VEAS-mode, too.)

I am using a 233 MHz (only 80 bogomips) Geode GX1. The performance is disappointing, but barely enough for dedicated functions. Playing mp3 requires roughly 80% of CPU time on the chip. Our text mode mp3 player updates the play time every second, so there is a video reflesh every second.

In console text mode, the sound is distorted whenever the video refresh occurs. Total system lock-up occurs once in a while.

In X, the sound is smooth and mp3 plays for hours.

Except for changing songs (audio is mutted), only one or two characters on the screen are updated. My guess is that X only updates the small region but the Geode VGA buffers compress and update the whole screen all the time.

I'm interested in the confused interrupt stack. How did you find out this?

Jürgen

That might not be the right words to use. But when it happens, the video would stop refreshing for several minitues, than come back with all the queued events (in X). It appears to be an internal watchdog timer waking up the video chip. Anyway, we don't try to dig too deep into the problem. As long as we multiplex the video and audio properly, we can avoid the problem.