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

[Takashi Iwai]

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.


thanks,

Takashi