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