[alsa-devel] Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

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