[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