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