Re: [alsa-devel] Backported sbxfi driver (UNTESTED!)
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;} 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.
thanks,
Takashi
On Fri, 2008-10-17 at 12:27 +0200, 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.
Only 96000Hz stereo works here as of 15 minutes ago. Following .asoundrc stanzas result in a hardware fault and return to BIOS:
pcm.xfi-dmix { type dmix ipc_key 1024 slave { pcm "hw:2,0" rate 96000 } }
pcm.xfi0 { type plug slave.pcm "xfi-dmix" }
pcm.default pcm.xfi0
Unfortunately, nothing was left in /var/log/kern.log.
William
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
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
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
On Sat, 2008-10-18 at 12:10 -0500, William Pitcock wrote:
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.
Figured it out. The hardware does not like period sizes larger than 4096. So we should manage a ringbuffer in the driver.
William
At Sat, 18 Oct 2008 12:17:04 -0500, William Pitcock wrote:
On Sat, 2008-10-18 at 12:10 -0500, William Pitcock wrote:
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...
"Break" means lock-up, or the sound quality?
likely due to their non-blocking tickless model. Trying with various period_time and buffer_size settings does not help.
Figured it out. The hardware does not like period sizes larger than 4096. So we should manage a ringbuffer in the driver.
Interesting. Is it a timer resolution issue, or loop size limitation?
Takashi
By the way, the frontpannel headphone does not work. Is it supposed to work?
http://us.creative.com/products/product.asp?category=209&subcategory=669...
(I Have this frontpannel but actually no X-RAM version of the X-Fi series, or at least I can't remember that it has X-RAM)
01:00.0 Multimedia audio controller: Creative Labs SB X-Fi Subsystem: Creative Labs X-Fi Platinum Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at 8c00 [size=32] Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi
01:00.0 0401: 1102:0005 Subsystem: 1102:0021 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at 8c00 [size=32] Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi
Kind regards Bjoern
Nothing in the X-Fi drive works yet.
William
On Sun, 2008-10-19 at 20:07 +0200, Bjoern Olausson wrote:
By the way, the frontpannel headphone does not work. Is it supposed to work?
http://us.creative.com/products/product.asp?category=209&subcategory=669...
(I Have this frontpannel but actually no X-RAM version of the X-Fi series, or at least I can't remember that it has X-RAM)
01:00.0 Multimedia audio controller: Creative Labs SB X-Fi Subsystem: Creative Labs X-Fi Platinum Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at 8c00 [size=32] Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mAPME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi
01:00.0 0401: 1102:0005 Subsystem: 1102:0021 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (1000ns min, 1250ns max), Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at 8c00 [size=32] Region 1: Memory at eb800000 (64-bit, non-prefetchable) [size=2M] Region 3: Memory at e4000000 (64-bit, non-prefetchable) [size=64M] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mAPME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Kernel driver in use: SB-XFi
Kind regards Bjoern _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (4)
-
Bjoern Olausson -
Takashi Iwai -
William Pitcock -
Xarteras