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

[Takashi Iwai]

At Sat, 18 Oct 2008 10:06:20 +0000,
Xarteras wrote:
> 
> 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.
> 
> The latest change in the timer code really broke playback for me.
> Sound now stutters every 2 seconds.
> It seems to go back to normal when I put back the TIMR_IP flag that was 
> commented out in that patch.

Oh, thanks for noticing it.  I took the bit back now.
Looks like the bit is different from what I expected...


Takashi