[alsa-devel] Backported sbxfi driver (UNTESTED!)
Takashi Iwai
tiwai at suse.de
Wed Oct 15 09:54:50 CEST 2008
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);
}
More information about the Alsa-devel
mailing list