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

[William Pitcock]

On Fri, 2008-10-17 at 12:27 +0200, Takashi Iwai wrote:
> At Fri, 17 Oct 2008 14:16:38 +0400,
> The Source wrote:
> > 
> > Takashi Iwai пишет:
> > > At Fri, 17 Oct 2008 14:01:55 +0400,
> > > The Source wrote:
> > >   
> > >> Takashi Iwai пишет:
> > >>     
> > >>> At Fri, 17 Oct 2008 13:58:20 +0400,
> > >>> The Source wrote:
> > >>>   
> > >>>       
> > >>>> Takashi Iwai пишет:
> > >>>>     
> > >>>>         
> > >>>>> At Fri, 17 Oct 2008 11:57:08 +0400,
> > >>>>> The Source wrote:
> > >>>>>   
> > >>>>>       
> > >>>>>           
> > >>>>>> Takashi Iwai пишет:
> > >>>>>>     
> > >>>>>>         
> > >>>>>>             
> > >>>>>>> At Thu, 16 Oct 2008 22:18:07 +0400,
> > >>>>>>> The Source wrote:
> > >>>>>>>   
> > >>>>>>>       
> > >>>>>>>           
> > >>>>>>>               
> > >>>>>>>>>> Ok. OpenAL with alsa also seem to cause problems.
> > >>>>>>>>>>     
> > >>>>>>>>>>         
> > >>>>>>>>>>             
> > >>>>>>>>>>                 
> > >>>>>>>>>>                     
> > >>>>>>>>> In both cases, check the period_size and buffer_size values (shown in
> > >>>>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params).
> > >>>>>>>>> And, try to aplay with these parameters, whether you get the similar
> > >>>>>>>>> problem.
> > >>>>>>>>>
> > >>>>>>>>> 	% aplay -v --period-size=xxx --buffer-size=yyy foo.wav
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Takashi
> > >>>>>>>>>
> > >>>>>>>>>   
> > >>>>>>>>>       
> > >>>>>>>>>           
> > >>>>>>>>>               
> > >>>>>>>>>                   
> > >>>>>>>> I'm sorry, but any attemp to play file with ossplay results in complete 
> > >>>>>>>> system hang with error:
> > >>>>>>>> unable to handle NULL ponter dereference at address 
> > >>>>>>>> 0000000000000008.....(hang, no more output).
> > >>>>>>>> I tried many wav formats. So I can't get error log or period and buffer 
> > >>>>>>>> sizes, sorry.
> > >>>>>>>>     
> > >>>>>>>>         
> > >>>>>>>>             
> > >>>>>>>>                 
> > >>>>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)?
> > >>>>>>>
> > >>>>>>> I'm wondering whether this has anything to do with the capture.
> > >>>>>>> Can you record the sound, and change the capture mixer element properly?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> thanks,
> > >>>>>>>
> > >>>>>>> Takashi
> > >>>>>>>
> > >>>>>>>   
> > >>>>>>>       
> > >>>>>>>           
> > >>>>>>>               
> > >>>>>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 
> > >>>>>> buffer size (default). Sound is choppy (sound pauses is more frequent 
> > >>>>>> when rate is lower).
> > >>>>>> However an attempt to play the same file with the same period and buffer 
> > >>>>>> sizes with aplay results in complete system hang.
> > >>>>>>     
> > >>>>>>         
> > >>>>>>             
> > >>>>> OK, that looks like a problem.  Looks like the timer resolution can be
> > >>>>> short like that, or something racy in the timer handling.
> > >>>>>
> > >>>>> Can you check whether this happens with XXX_SYSTEM_TIMER, too?
> > >>>>>
> > >>>>> Or, does the patch below avoid the problem, at least?
> > >>>>>
> > >>>>>
> > >>>>> thanks,
> > >>>>>
> > >>>>> Takashi
> > >>>>>
> > >>>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c
> > >>>>> index 26a6cd3..5ceb228 100644
> > >>>>> --- a/sound/pci/sbxfi/sbxfi.c
> > >>>>> +++ b/sound/pci/sbxfi/sbxfi.c
> > >>>>> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks)
> > >>>>>  #else
> > >>>>>  
> > >>>>>  #define MAX_TICKS	((1 << 13) - 1)
> > >>>>> +#define MIN_TICKS	1000		/* FIXME: really so? */
> > >>>>>  
> > >>>>>  static void sbxfi_init_timer(struct sbxfi *chip)
> > >>>>>  {
> > >>>>> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks)
> > >>>>>  	LOG(2, "SET TIMER TICKS = %d\n", ticks);
> > >>>>>  	if (ticks > MAX_TICKS)
> > >>>>>  		ticks = MAX_TICKS;
> > >>>>> +	else if (ticks < MIN_TICKS)
> > >>>>> +		ticks = MIN_TICKS;
> > >>>>>  	sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP);
> > >>>>>  }
> > >>>>>  static void sbxfi_stop_timer(struct sbxfi *chip)
> > >>>>>
> > >>>>>   
> > >>>>>       
> > >>>>>           
> > >>>> After patch:
> > >>>>
> > >>>> Without system timer:
> > >>>>
> > >>>> aplay --period-size=1024 96000_16_Stereo.wav
> > >>>> Plays fine
> > >>>>
> > >>>> aplay --period-size=1024 22050_16_Mono.wav
> > >>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> > >>>> Hang
> > >>>>
> > >>>> With system timer:
> > >>>>
> > >>>> aplay --period-size=1024 96000_16_Stereo.wav
> > >>>> Superglitch. Each sample is played many times before advancing to next one.
> > >>>>
> > >>>> aplay --period-size=1024 22050_16_Mono.wav
> > >>>> Instant reboot.
> > >>>>     
> > >>>>         
> > >>> Just to be sure: you don't enable XXX_CONT_RATE, right?
> > >>> It's known to be buggy, so disabled as default now.
> > >>>
> > >>>
> > >>> Takashi
> > >>>
> > >>>   
> > >>>       
> > >> It is disabled for me too.
> > >>     
> > >
> > > And the patch didn't help?
> > >
> > >
> > > Takashi
> > >
> > >   
> > Only 96000Hz Stereo without system timer plays fine after patch.
> 
> Please elaborate?  You mean 22.5k still doesn't work with the patch?
> Does 22.5kHz ever work with other parameters?  It'd be really helpful
> if you get the full Oops log...
> 
> The patch affects only the emu20k1 timer.  The system timer stuff
> isn't touched by it.
> 
> The reboot implies that it's unlikely the timer but the driver wrote
> something wrong (unless you have the set up that the kernel traps and
> automatically reboot).  But, it's nothing but a wild guess at this
> point.
> 
> Anyway, I updated the driver code a bit again.  Please check the
> latest one.

Only 96000Hz stereo works here as of 15 minutes ago. Following .asoundrc
stanzas result in a hardware fault and return to BIOS:

pcm.xfi-dmix {
    type dmix
    ipc_key 1024
    slave {
        pcm "hw:2,0"
        rate 96000
    }
}

pcm.xfi0 {
    type plug
    slave.pcm "xfi-dmix"
}

pcm.default pcm.xfi0

Unfortunately, nothing was left in /var/log/kern.log.

William
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20081017/39fe9017/attachment.sig