Re: Backported sbxfi driver (UNTESTED!)

[The Source <thesourcehim@gmail.com>]

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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel