At Tue, 14 Oct 2008 11:58:00 +0400,The Source wrote:> > Takashi Iwai пишет:> > At Tue, 14 Oct 2008 11:23:42 +0400,> > The Source wrote:> > > >> Takashi Iwai пишет:> >> > >>> At Mon, 13 Oct 2008 23:21:47 +0400,> >>> Alexey Bazhin wrote:> >>> > >>> > >>>> On Mon, 13 Oct 2008 18:05:49 +0200> >>>> Takashi Iwai <tiwai@xxxxxxx> wrote:> >>>>> >>>> > >>>> > >>>>> At Mon, 13 Oct 2008 18:02:08 +0200,> >>>>> I wrote:> >>>>> > >>>>> > >>>>>> At Mon, 13 Oct 2008 17:43:03 +0200,> >>>>>> I wrote:> >>>>>> > >>>>>> > >>>>>>> For example, the latest snapshot I uploaded now has> >>>>>>> alsa-kernel/HEAD: a3e1ef74a8ec8b6e3c30f7aa06c5d5d2f2bea7a9 Merge> >>>>>>> branch 'topic/sbxfi'> >>>>>>> > >>>>>>> > >>>>>> ... and again updated to:> >>>>>> 5d425dd626d107ff2b2ea97c27068f7ee4b36dd1 Merge branch> >>>>>> 'topic/sbxfi'> >>>>>> > >>>>>> > >>>>> So, guys, please check the latest one.> >>>>>> >>>>> If the hang up still occurs with this version, then try to define> >>>>> XXX_SYSTEM_TIMER in sbxfi.c, which is undefined as default.> >>>>> With this build option, the driver will use the system timer instead> >>>>> of emu20k1 timer irqs.> >>>>>> >>>>> If this still doesn't help, try to remove all spinlocks. That is,> >>>>> just comment out all spin_lock*() and spin_unlock*() calls to avoid> >>>>> spin deadlocks. Of course, it can be racy, but better than a spin> >>>>> deadlock.> >>>>> > >>>>> > >>>> Now it doesn't hangs :)> >>>> > >>>> > >>> Glad to hear. Did you have to use XXX_SYSTEM_TIMER or any workaround> >>> needed? Or, did it work as is?> >>>> >>> > >>> > >>>> but speakers-test produces crackling sine and> >>>> fails on test...> >>>> > >>>> > >>> Do you mean it aborts some time later after starting the stream?> >>> Could you show the kernel messages? The default debug level should> >>> suffice, I guess. If any, try debug=2.> >>>> >>> > >>> > >>>> root@mayonaka:~# speaker-test -c 2 -r 96000 -t> >>>> sine > >>>>> >>>> speaker-test 1.0.15> >>>>> >>>> Playback device is default> >>>> Stream parameters are 96000Hz, S16_LE, 2 channels> >>>> Sine wave rate is 440.0000Hz> >>>> Rate set to 96000Hz (requested 96000Hz)> >>>> Buffer size range from 32 to 16384> >>>> Period size range from 32 to 16384> >>>> Using max buffer size 16384> >>>> Periods = 4> >>>> was set period_size = 4096> >>>> was set buffer_size = 16384> >>>> 0 - Front Left> >>>> Write error: -5,Input/output error> >>>> xrun_recovery failed: -5,Input/output error> >>>> Transfer failed: Operation not permitted> >>>>> >>>> Also i tried mplayer, 96khz works almost fine (very rare cracklings),> >>>> 48khz plays slow (like playing 96khz sample on 48khz rate without> >>>> resampling), 44.1khz doesn't work at all (mplayer doesn't even> >>>> show that it plays).> >>>> > >>>> > >>> How about the patch below for 48kHz?> >>>> >>> Not sure whether 44.1kHz works at all with the current driver code.> >>> I just guessed that the pitch parameter would handle that. But, maybe> >>> it's not enough...> >>>> >>> > >>> > >>>> Master control on mixer seems to be working fine.> >>>> > >>>> > >>> OK.> >>>> >>> [BTW, it'd be appreciated if you add my address to Cc (or, To: my> >>> address and Cc: to ML like other people do), so that I can check your> >>> post quickly.]> >>>> >>>> >>> thanks,> >>>> >>> Takashi> >>>> >>>> >>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c> >>> index 3fde6a9..47ba941 100644> >>> --- a/sound/pci/sbxfi/sbxfi.c> >>> +++ b/sound/pci/sbxfi/sbxfi.c> >>> @@ -1005,7 +1005,8 @@ static void sbxfi_setup_play_pitch(struct sbxfi *chip,> >>> unsigned int pitch, pitch_ch;> >>> > >>> /* convert to fixed-point 8.24 format */> >>> - pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate);> >>> + /* pitch = div_u64(runtime->rate * (1ULL << 24), chip->base_rate); */> >>> + pitch = div_u64(runtime->rate * (1ULL << 24), 96000);> >>> > >>> for (i = 0; i < 2; i++) {> >>> /* write the pitch to param ring of the corresponsing SRC> >>> _______________________________________________> >>> Alsa-devel mailing list> >>> Alsa-devel@xxxxxxxxxxxxxxxx> >>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel> >>>> >>> > >>> > >> Ok, I downloaded todays (14th October) snapshot. At least ftp sais the > >> file alsa-driver-unstable-snapshot.tar.bz2 is of 14.10.2008.> >> > >> > Check HEAD files to make sure it's the latest one as I posted.> >> > > >> I extracted it, ran configure, make , make install. No reboot on aplay > >> now, but Oops occurs. Tried with sysytem timer (make clean, changed > >> #undef XXX_SYSTEM_TIMER to #define XXX_SYSTEM_TIMER in sbxfi.c, > >> configure, make, make install). Oops again.> >> Here's the error message:> >> Playing foo.wav: Signed 16bit Little Endian, Rate 22050Hz, Mono> >> > >> > As I wrote, try 96kHz samples at first.> >> > > >> BUG: unable to handle NULL pointer dereference at 0000000000000008> >> IP: <4> Spurious LAPIC timer interrupt on CPU 1> >> [<ffffffff811410c7>] __list_add+0x1/0x5b> >> PGD 14c14e067 PUD 14c14f067> >> PMD 14e576067 PTE 0> >> Oops: 0000 [1]> >> > >> > More log below that point please. It contains the stack trace.> >> >> > thanks,> >> > Takashi> >> > > Where can I get more log? I posted here console output, after that > system hangs completely.
That's bad. Usually you have more logs when you run dmesg.Does this happen after the fresh reboot, too, right?
[BTW, please post to my address and add Cc to ML instead of posting only to ML. Most developer MLs (like LKML) prefer it.]
Takashi_______________________________________________Alsa-devel mailing listAlsa-devel@xxxxxxxxxxxxxxxxxxxx://mailman.alsa-project.org/mailman/listinfo/alsa-devel
