Re: [alsa-devel] Backported sbxfi driver (UNTESTED!)
At Thu, 16 Oct 2008 19:06:58 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 19:00:16 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 18:41:08 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 18:15:45 +0400, The Source wrote:
> Takashi Iwai пишет: > > > >> At Thu, 16 Oct 2008 17:36:04 +0400, >> The Source wrote: >> >> >> >> >>>>> And, which X-Fi model do you have? >>>>> Please show the lspci -nv output, too. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> I've got the X-Fi Elite Pro. >>>> That's The one with the external In/Out box. >>>> >>>> Speaking of which, the headphone jack on it does not output a signal >>>> yet, the signal only goes to line out. >>>> >>>> There's some relais on the card that seem to switch these, they click >>>> multiple times with the windows driver and not all all with yours, I >>>> think that's the reason :) >>>> >>>> >>>> >>>> >>>> >>> Original OSS driver doesn't output to external block also, so it >>> wouldn't be easy to make this support I think. >>> >>> >>> >>> >> The values for port->conv[0] and [1] values in sbxfi_playback_open() >> might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL >> and DAI_CH_I2SAR, as default. You can try other values, such as, >> DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on. >> >> >> Takashi >> >> >> >> >> > Latest snapshot has a bug: > make[3]: *** No rule to make target > `/mnt/e/temp/alsa-driver-unstable/acore/jack.o', needed by > `/mnt/e/temp/alsa-driver-unstable/acore/snd.o'. Stop. > > > Already fixed.
Takashi
In file included from /mnt/e/temp/alsa-driver-unstable/acore/jack.c:3: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_new’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: (Each undeclared identifier is reported only once /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: for each function it appears in.) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_report’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:157: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function)
Hmm, it seems broken for older kernels right now. The easy workaround is to pass --with-cards=sbxfi to configure.
Anyway, I'll fix it now.
thanks,
Takashi
--Hey, man, this is cool! Plays just fine (volume ok, speed ok, no --glitches) with 96000, 48000, 44100, 22050, 16/24 bit, Stereo and --Mono!! --I didn't change anything in the source code, so I don't use system --timer. Yes!!
However oss (alsa-emulated) is unstable. I'll test more.
Could be due to 96kHz base-rate? Try base_rate=48000. If you get still problems, please show the kernel logs with debug=2.
BTW, the jack.c compile error should have been fixed now (hopefully). Let me know if you still have the build errors.
thanks,
Takashi
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
Just wanted to ask if someone has some good wav files at different samplerates mono/stereo etc etc [for all cases] (maybe with some voice instead of the sinus sound I am using.)
Would be nice if we could make our tests based on the same wav files.
Would make it easier to compare the results.
Kind regards Bjoern
Bjoern Olausson пишет:
Just wanted to ask if someone has some good wav files at different samplerates mono/stereo etc etc [for all cases] (maybe with some voice instead of the sinus sound I am using.)
Would be nice if we could make our tests based on the same wav files.
Would make it easier to compare the results.
Kind regards Bjoern _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
You can convert wav file to desired format with sox.
Takashi Iwai пишет:
At Thu, 16 Oct 2008 19:06:58 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 19:00:16 +0400, The Source wrote:
Takashi Iwai пишет:
At Thu, 16 Oct 2008 18:41:08 +0400, The Source wrote:
Takashi Iwai пишет:
> At Thu, 16 Oct 2008 18:15:45 +0400, > The Source wrote: > > > > >> Takashi Iwai пишет: >> >> >> >> >>> At Thu, 16 Oct 2008 17:36:04 +0400, >>> The Source wrote: >>> >>> >>> >>> >>> >>>>>> And, which X-Fi model do you have? >>>>>> Please show the lspci -nv output, too. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I've got the X-Fi Elite Pro. >>>>> That's The one with the external In/Out box. >>>>> >>>>> Speaking of which, the headphone jack on it does not output a signal >>>>> yet, the signal only goes to line out. >>>>> >>>>> There's some relais on the card that seem to switch these, they click >>>>> multiple times with the windows driver and not all all with yours, I >>>>> think that's the reason :) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Original OSS driver doesn't output to external block also, so it >>>> wouldn't be easy to make this support I think. >>>> >>>> >>>> >>>> >>>> >>> The values for port->conv[0] and [1] values in sbxfi_playback_open() >>> might play some role. It's I2SA_L and I2SA_R, alias DAI_CH_I2SAL >>> and DAI_CH_I2SAR, as default. You can try other values, such as, >>> DAI_CH_I2SBL, DAI_CH_I2SA1L, and so on. >>> >>> >>> Takashi >>> >>> >>> >>> >>> >>> >> Latest snapshot has a bug: >> make[3]: *** No rule to make target >> `/mnt/e/temp/alsa-driver-unstable/acore/jack.o', needed by >> `/mnt/e/temp/alsa-driver-unstable/acore/snd.o'. Stop. >> >> >> >> > Already fixed. > > > Takashi > > > > > In file included from /mnt/e/temp/alsa-driver-unstable/acore/jack.c:3: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_new’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: (Each undeclared identifier is reported only once /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:107: error: for each function it appears in.) /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c: In function ‘snd_jack_report’: /mnt/e/temp/alsa-driver-unstable/acore/../alsa-kernel/core/jack.c:157: error: ‘SW_MICROPHONE_INSERT’ undeclared (first use in this function)
Hmm, it seems broken for older kernels right now. The easy workaround is to pass --with-cards=sbxfi to configure.
Anyway, I'll fix it now.
thanks,
Takashi
--Hey, man, this is cool! Plays just fine (volume ok, speed ok, no --glitches) with 96000, 48000, 44100, 22050, 16/24 bit, Stereo and --Mono!! --I didn't change anything in the source code, so I don't use system --timer. Yes!!
However oss (alsa-emulated) is unstable. I'll test more.
Could be due to 96kHz base-rate? Try base_rate=48000. If you get still problems, please show the kernel logs with debug=2.
BTW, the jack.c compile error should have been fixed now (hopefully). Let me know if you still have the build errors.
thanks,
Takashi
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.
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
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
Err, I'm not sure I understand. Could you please explain step-by-step?
At Fri, 17 Oct 2008 10:26:27 +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
Err, I'm not sure I understand. Could you please explain step-by-step?
Just run arecord to record something. And, change the recording source via mixer.
So far, I got little report about recording, and I'm not sure whether it works at all.
Takashi
Takashi Iwai пишет:
At Fri, 17 Oct 2008 10:26:27 +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
Err, I'm not sure I understand. Could you please explain step-by-step?
Just run arecord to record something. And, change the recording source via mixer.
So far, I got little report about recording, and I'm not sure whether it works at all.
Takashi
Should I change source WHILE recording or AFTER recording? Should I change it to OSS or just to another ALSA source?
Takashi Iwai пишет:
At Fri, 17 Oct 2008 10:26:27 +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
Err, I'm not sure I understand. Could you please explain step-by-step?
Just run arecord to record something. And, change the recording source via mixer.
So far, I got little report about recording, and I'm not sure whether it works at all.
Takashi
I tried arecord with several sources and formats. I don't have mic or other recording device so the file is silent (and only 1 second length, I terminated arecord after 5 or so seconds, I don't know is 1s length is ok or not in this case), but at least it doesn't crash. Using ossrecord leads to NULL pointer dereference at 0000000000000008 and hang.
Takashi Iwai wrote:
At Fri, 17 Oct 2008 10:26:27 +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
Err, I'm not sure I understand. Could you please explain step-by-step?
Just run arecord to record something. And, change the recording source via mixer.
So far, I got little report about recording, and I'm not sure whether it works at all.
I just tested ossplay and arecord. For me both result in a spontanous crash back to BIOS without leaving any traces in the log files. Everything else works fine so far.
Jan Wolf
Xarteras пишет:
Takashi Iwai wrote:
At Fri, 17 Oct 2008 10:26:27 +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.wavTakashi
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
Err, I'm not sure I understand. Could you please explain step-by-step?
Just run arecord to record something. And, change the recording source via mixer.
So far, I got little report about recording, and I'm not sure whether it works at all.
I just tested ossplay and arecord. For me both result in a spontanous crash back to BIOS without leaving any traces in the log files. Everything else works fine so far.
Jan Wolf
Seems that only one application at a time can use alsa. All other apps say they can't initialize sound until I close the first app.
At Fri, 17 Oct 2008 13:17:28 +0400, The Source wrote:
Xarteras пишет:
Takashi Iwai wrote:
At Fri, 17 Oct 2008 10:26:27 +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
Err, I'm not sure I understand. Could you please explain step-by-step?
Just run arecord to record something. And, change the recording source via mixer.
So far, I got little report about recording, and I'm not sure whether it works at all.
I just tested ossplay and arecord. For me both result in a spontanous crash back to BIOS without leaving any traces in the log files. Everything else works fine so far.
Jan Wolf
Seems that only one application at a time can use alsa. All other apps say they can't initialize sound until I close the first app.
Yes, it's a design, so far. Right now, DSP is bypassed and the SRC is directly connected (as far as I understood from the code). So, I guess multi-playing won't work without DSP codes.
You can use dmix instead. At least, there is one positive report :) For testing, just run like % aplay -Dplug:dmix foo.wav
Takashi
At Fri, 17 Oct 2008 09:00:30 +0000, Xarteras wrote:
Takashi Iwai wrote:
At Fri, 17 Oct 2008 10:26:27 +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
Err, I'm not sure I understand. Could you please explain step-by-step?
Just run arecord to record something. And, change the recording source via mixer.
So far, I got little report about recording, and I'm not sure whether it works at all.
I just tested ossplay and arecord. For me both result in a spontanous crash back to BIOS without leaving any traces in the log files. Everything else works fine so far.
OK, then the problem is consistent. It's a bit tough to check without a proper log. How about running with strace? What is the last syscall before the dead end?
thanks,
Takashi
Takashi Iwai wrote:
At Fri, 17 Oct 2008 09:00:30 +0000, Xarteras wrote:
Takashi Iwai wrote:
At Fri, 17 Oct 2008 10:26:27 +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
Err, I'm not sure I understand. Could you please explain step-by-step?
Just run arecord to record something. And, change the recording source via mixer.
So far, I got little report about recording, and I'm not sure whether it works at all.
I just tested ossplay and arecord. For me both result in a spontanous crash back to BIOS without leaving any traces in the log files. Everything else works fine so far.
OK, then the problem is consistent. It's a bit tough to check without a proper log. How about running with strace? What is the last syscall before the dead end?
I just noticed I still had a dsnoop/dmix set up and renamed asound.conf for retesting. Now at least arecord doesn't crash the system anymore, but it only returns silence (Despite a mic being connected).
ossplay still crashes though and strace isn't of much use. Running ossplay causes a sys reset so fast the strace output cannot even be flushed to disk anymore, neverless be up long enough to read it on the screen.
Jan Wolf
On Fri, 2008-10-17 at 09:50 +0000, Xarteras wrote:
ossplay still crashes though and strace isn't of much use. Running ossplay causes a sys reset so fast the strace output cannot even be flushed to disk anymore, neverless be up long enough to read it on the screen.
A serial console may help you there, assuming you have two machines.
Jan Wolf
Regards, Tony V.
Tony Vroon wrote:
On Fri, 2008-10-17 at 09:50 +0000, Xarteras wrote:
ossplay still crashes though and strace isn't of much use. Running ossplay causes a sys reset so fast the strace output cannot even be flushed to disk anymore, neverless be up long enough to read it on the screen.
A serial console may help you there, assuming you have two machines.
Good idea :)
Just tried it, but even a 115200 baud serial connection isn't fast enough to give me more than the first three lines of useless strace output before it's back to BIOS.
Jan Wolf
On Fri, Oct 17, 2008 at 12:35 PM, Xarteras xarteras@nostalgicnetworxx.org wrote:
Tony Vroon wrote:
On Fri, 2008-10-17 at 09:50 +0000, Xarteras wrote:
ossplay still crashes though and strace isn't of much use. Running ossplay causes a sys reset so fast the strace output cannot even be flushed to disk anymore, neverless be up long enough to read it on the screen.
A serial console may help you there, assuming you have two machines.
Good idea :)
Just tried it, but even a 115200 baud serial connection isn't fast enough to give me more than the first three lines of useless strace output before it's back to BIOS.
Jan Wolf _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Same here, not with serial, not with ssh, not even with a Camera recording the screen....
No logs either...
By the way, -amarok with xine as backand using ALSA works -Flash movies with sound in Opera work -Xine works flawless (nice sound)...just watched "Big_bug_bunny_080p stereo.ogg"
Now I am listening to my favourite song Diana_Krall_-_Black_Crow.mp3 (256kbps 44100Hz) with xine. Clear, distortionfree, lovely sound!
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.
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)
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.
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
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.
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
participants (5)
-
Bjoern Olausson -
Takashi Iwai -
The Source -
Tony Vroon -
Xarteras