At Wed, 15 Oct 2008 12:14:57 +0400, The Source wrote:

Takashi Iwai пишет:

...

At Wed, 15 Oct 2008 11:47:00 +0400, The Source wrote:

...

Takashi Iwai пишет:

...

At Wed, 15 Oct 2008 11:16:32 +0400, The Source wrote:

...

Takashi Iwai пишет:

...

At Tue, 14 Oct 2008 15:24:22 +0400, The Source wrote:

> By the way, note, that not rate may cause oops but number of channles > for example (wav that causes oops has mono mode and the one that just > plays silently - stereo. Also the oops sample is 16bit, silent one is > 24bit). > > > This is an important information. The driver basically supports only 16bit stereo samples natively. The others are covered by alsa-lib, and this involves with the mmap mode.

But I still wonder why 16bit mode.

OK, the below is *THE* test I'd like ask you guys to try first.

• Build the driver with --with-debug=detect option
• Load the driver with debug=2 module option
• Prepare a WAV file with 96kHz 16bit stereo, e.g. converted via sox
• Raise the Master volume to the max
• Run "aplay this.wav"

At *each* run, check your kernel message. If you get Oops, copy the whole log immediately.

• If you get a DMA error or so in the kernel message, try to define XXX_SYSTEM_TIMER in sbxfi.c, rebuild and reinstall the driver. Run the same test.

• If still any serious problem, load the module with debug=3 option, and get the whole kernel message with full register accesses.

thanks,

Takashi

I've done what you have asked. I've got no oopses or other things like that. But again not sound. I've tried with debug=2 and debug=3. Attaching the whole dmesg output.

Thanks. Judging from your logs, it seems that the timer IRQ isn't generated as expected, or the pointer (SRCCA register read) doesn't work, or all broken.

Could you try with XXX_SYSTEM_TIMER? This eliminates, at least, the timer issue.

Takashi

I can't use system timer. changing #undef XXX_SYSTEM_TIMER to #define XXX_SYSTEM_TIMER causes this: In file included from /mnt/e/temp/alsa-driver-unstable/pci/sbxfi/sbxfi.c:2: /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c: In function ‘sbxfi_timer_handle’: /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: error: ‘status’ undeclared (first use in this function) /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: error: (Each undeclared identifier is reported only once /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: error: for each function it appears in.) /mnt/e/temp/alsa-driver-unstable/include/../alsa-kernel/pci/sbxfi/sbxfi.c:252: warning: too many arguments for format

Try the patch below. In case you're using snapshot tarball, apply it with -p2 on alsa-kernel directory.

Takashi

diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 9ff5fc4..d6b5b34 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -249,7 +249,7 @@ static void sbxfi_handle_timer_callback(struct sbxfi *chip);

static void sbxfi_timer_handle(unsigned long data) {

• LOG(2, "TIMER ISR\n", status);

• LOG(2, "TIMER ISR\n"); sbxfi_handle_timer_callback((struct sbxfi *)data);

}

Ok, I tested again and found that sound is actually played (with and without system timer),

Good to hear a positive thing :)

but:

1. The volume is extremely low. I had not only set volume to maximum in

alsamixer but also set my audio 5.1 system volume to maximum to hear a sound.

This sounds like an amp isn't turned on somewhere. Possibly a GPIO setting.

Alexey, what about your hardware? Is it also so extremely low?

2. The sound is very slow and glitchy. It plays much slower that it

should and constant glitches occur.

The glitches might be the result of the rate inconsistency. How slow is it? Is it somewhat playing half-rate samples? You can check it on the normally running device, for example,

% aplay -traw -fS16_LE -c2 -r48000 SOME-96K.wav

will play 96kHz samples in 48kHz.

thanks,

Takashi