Takashi Iwai пишет:
Ok, I tested again and found that sound is actually played (with and without system timer), 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. 2. The sound is very slow and glitchy. It plays much slower that it should and constant glitches occur.At Wed, 15 Oct 2008 11:47:00 +0400, The Source wrote:Takashi Iwai пишет:I can't use system timer. changing #undef XXX_SYSTEM_TIMER to #define XXX_SYSTEM_TIMER causes this:At Wed, 15 Oct 2008 11:16:32 +0400, The Source wrote:Takashi Iwai пишет: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.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, TakashiThanks. 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. TakashiIn 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 formatTry 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); }
Attaching dmesg output.
Attachment:
dmesg.out.bz2
Description: application/bzip
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
