[alsa-devel] Backported sbxfi driver (UNTESTED!)

[Takashi Iwai]

At Tue, 14 Oct 2008 12:55:01 +0400,
The Source wrote:
> 
> Takashi Iwai пишет:
> > At Tue, 14 Oct 2008 12:48:31 +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 at suse.de> 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 at 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 at alsa-project.org
> >>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >>>
> >>>   
> >>>       
> >> Tried 96KHz sample (24bit, Little Endian, 96000Hz, Stereo). No crash, 
> >> hang, reboot. oops, panic etc. But no sound too.
> >>     
> >
> > Strange.  Oops shouldn't depend on the rate, at least...
> >
> > Did you raise the master volume?
> >
> >
> > Takashi
> >
> >   
> Yes, to 100%

OK, could you then show the kernel messages?
Now the driver must show something useful.

Also, if you load the driver with debug=3 module option, it will log
the whole register accesses.  Note that the whole can be really
long, so do it just only when you want.


Takashi