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

[Xarteras]

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.

Jan Wolf