[alsa-devel] Backported sbxfi driver (UNTESTED!)
Takashi Iwai
tiwai at suse.de
Fri Oct 17 12:04:15 CEST 2008
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
More information about the Alsa-devel
mailing list