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 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@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > Ok, got the dmesg output with debug=3. Hope that helps.