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 listAlsa-devel@xxxxxxxxxxxxxxxxxxxx://mailman.alsa-project.org/mailman/listinfo/alsa-devel
