[nas] Re: BUG: client sound played at wrong frequency

[Jon Trulson]

On Wed, 5 Dec 2001, Tobias Diedrich wrote:

> Date: Wed, 5 Dec 2001 01:29:58 +0100
> From: Tobias Diedrich <td at informatik.uni-hannover.de>
> To: nas at radscan.com
> Subject: [nas] Re: BUG: client sound played at wrong frequency
> 
> Tobias Diedrich wrote:
> > I just noticed a bug:
> > 
> > If I start a video which is using 44100Hz, then start another one which
> > uses 48000Hz, the first one is played at the wrong frequency, after the
> > second one starts and even when the second one is finished.
> > If I do it the other way around both are played right until I stop the
> > 48000Hz video, after which the 44100Hz video is played too fast again.
> > 
> > (Installed debian package version is 1.4.2-5)
> 
> OK, dirty hack:
> Always set samplerate to Max.

	Hmm... 

> This probably means nasd will use rate conversion for most flows. The
> correct fix could be to register an auSetSampleRateCB for each flow,
> which will adjust the flows data to the new rate and could probably
> also increase the rate (rate should always be min(Maxrate,max(all flow
> rates)) IMHO).
> 

	Each server implements the auSetSampleRateCB callback... It's kind
of required ;-)  For voxware this is the setSampleRate() function in
auvoxware.c (dda).  It seems to be doing what it's supposed to do.

	What is probably happening is gratuitous sample rate changes
when a flow is in progress.  I'm not sure what should be the best
behavior...

	1. Go ahead and set the sample rate, but resample any flow(s)
neccessary to compensate (via up/down sampling)
	2. When multiple flows with differing sample rates are running,
the first one wins, and the rest are resampled to compensate.  
	3. Always run at the maximum hw sample rate and resample any flows
that don't match it.

	I know that doing #1, at least on the hpux server, is
problematic... I found I had to completely reset the device before I could
change the sample rate after data had been played on it.  This will result
in audible noise and lost data if we do this when flows were active at the
time (a given, in this situation).

	With #2, what should be the behavior if the first flow ends
(defining the hw sample rate), while others are still running?   Wait till
they all end before allowing a hw sample rate change?  Probably,  but that
has it's own drawbacks...

	#3 seems... a potential waste of CPU and probably a loss of
quality, as the resampler isn't very sophisticated.  

	I kind of lean toward 2, though it's a little more complicated
to implement...

	Thoughts? Patches ;-)
	
[...]

-- 
Jon Trulson    mailto:jon at radscan.com
ID: 1A9A2B09, FP: C23F328A721264E7 B6188192EC733962
PGP keys at http://radscan.com/~jon/PGPKeys.txt
#include <std/disclaimer.h>
Bad Color Temperature, Too much Peach.