At Sat, 18 Oct 2008 10:06:20 +0000,Xarteras wrote:> > 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.
Oh, thanks for noticing it. I took the bit back now.Looks like the bit is different from what I expected...
Takashi_______________________________________________Alsa-devel mailing listAlsa-devel@xxxxxxxxxxxxxxxxxxxx://mailman.alsa-project.org/mailman/listinfo/alsa-devel
