[alsa-devel] Backported sbxfi driver (UNTESTED!)
William Pitcock
nenolod at sacredspiral.co.uk
Sat Oct 18 19:10:19 CEST 2008
On Sat, 2008-10-18 at 17:06 +0200, Takashi Iwai wrote:
> 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...
Works in mpg123 (use -r 96000) again, breaks in Audacious and mplayer...
likely due to their non-blocking tickless model. Trying with various
period_time and buffer_size settings does not help.
William
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20081018/deff3681/attachment-0001.sig
More information about the Alsa-devel
mailing list