Chris@41: Chris@41:

Frequently Asked Questions

Chris@41:

Chris@41: Q1 : Is it normal for the output of libsamplerate to be louder Chris@41: than its input?

Chris@41: Q2 : On Unix/Linux/MacOSX, what is the best way of detecting Chris@41: the presence and location of libsamplerate and its header file using Chris@41: autoconf?

Chris@41: Q3 : If I upsample and downsample to the original rate, for Chris@41: example 44.1->96->44.1, do I get an identical signal as the one before the Chris@41: up/down resampling?

Chris@41: Q4 : If I ran src_simple (libsamplerate) on small chunks (160 Chris@41: frames) would that sound bad?

Chris@41: Q5 : I'm using libsamplerate but the high quality settings Chris@41: sound worse than the SRC_LINEAR converter. Why?

Chris@41: Q6 : I'm use the SRC_SINC_* converters and up-sampling by a ratio of Chris@41: 2. I reset the converter and put in 1000 samples and I expect to get 2000 Chris@41: samples out, but I'm getting less than that. Why?

Chris@41: Q7 : I have input and output sample rates that are integer Chris@41: values, but the API wants me to divide one by the other and put the result Chris@41: in a floating point number. Won't this case problems for long running Chris@41: conversions?

Chris@41:

Chris@41:

Chris@41: Chris@41: Chris@41:

Q1 : Is it normal for the output of libsamplerate to be louder Chris@41: than its input?

Chris@41:

Chris@41: The output of libsamplerate will be roughly the same volume as the input. Chris@41: However, even if the input is strictly in the range (-1.0, 1.0), it is still Chris@41: possible for the output to contain peak values outside this range. Chris@41:

Chris@41:

Chris@41: Consider four consecutive samples of [0.5 0.999 0.999 0.5]. Chris@41: If we are up sampling by a factor of two we need to insert samples between Chris@41: each of the existing samples. Chris@41: Its pretty obvious then, that the sample between the two 0.999 values should Chris@41: and will be bigger than 0.999. Chris@41:

Chris@41:

Chris@41: This means that anyone using libsamplerate should normalize its output before Chris@41: doing things like saving the audio to a 16 bit WAV file. Chris@41:

Chris@41: Chris@41: Chris@41: Chris@41: Chris@41: Chris@41:

Q2 : On Unix/Linux/MacOSX, what is the best way of detecting Chris@41: the presence and location of libsamplerate and its header file using Chris@41: autoconf?

Chris@41: Chris@41:

Chris@41: libsamplerate uses the pkg-config (man pkg-config) method of registering itself Chris@41: with the host system. Chris@41: The best way of detecting its presence is using something like this in configure.ac Chris@41: (or configure.in): Chris@41:

Chris@41: Chris@41:

Chris@41:     PKG_CHECK_MODULES(SAMPLERATE, samplerate >= 0.1.3,
Chris@41:             ac_cv_samplerate=1, ac_cv_samplerate=0)
Chris@41: 
Chris@41:     AC_DEFINE_UNQUOTED([HAVE_SAMPLERATE],${ac_cv_samplerate},
Chris@41:             [Set to 1 if you have libsamplerate.])
Chris@41: 
Chris@41:     AC_SUBST(SAMPLERATE_CFLAGS)
Chris@41:     AC_SUBST(SAMPLERATE_LIBS)
Chris@41:

Chris@41:

Chris@41: This will automatically set the SAMPLERATE_CFLAGS and SAMPLERATE_LIBS Chris@41: variables which can be used in Makefile.am or Makefile.in like this: Chris@41:

Chris@41:

Chris@41:         SAMPLERATE_CFLAGS = @SAMPLERATE_CFLAGS@
Chris@41:         SAMPLERATE_LIBS = @SAMPLERATE_LIBS@
Chris@41:

Chris@41: Chris@41:

Chris@41: If you install libsamplerate from source, you will probably need to set the Chris@41: PKG_CONFIG_PATH environment variable's suggested at the end of the Chris@41: libsamplerate configure process. For instance on my system I get this: Chris@41:

Chris@41:

Chris@41:     -=-=-=-=-=-=-=-=-=-= Configuration Complete =-=-=-=-=-=-=-=-=-=-=-
Chris@41: 
Chris@41:       Configuration summary :
Chris@41: 
Chris@41:         Version : ..................... 0.1.3
Chris@41:         Enable debugging : ............ no
Chris@41: 
Chris@41:       Tools :
Chris@41: 
Chris@41:         Compiler is GCC : ............. yes
Chris@41:         GCC major version : ........... 3
Chris@41: 
Chris@41:       Extra tools required for testing and examples :
Chris@41: 
Chris@41:         Have FFTW : ................... yes
Chris@41:         Have libsndfile : ............. yes
Chris@41:         Have libefence : .............. no
Chris@41: 
Chris@41:       Installation directories :
Chris@41: 
Chris@41:         Library directory : ........... /usr/local/lib
Chris@41:         Program directory : ........... /usr/local/bin
Chris@41:         Pkgconfig directory : ......... /usr/local/lib/pkgconfig
Chris@41:

Chris@41: Chris@41: Chris@41: Chris@41: Chris@41: Chris@41:

Q3 : If I upsample and downsample to the original rate, for Chris@41: example 44.1->96->44.1, do I get an identical signal as the one before the Chris@41: up/down resampling?

Chris@41:

Chris@41: The short answer is that for the general case, no, you don't. Chris@41: The long answer is that for some signals, with some converters, you will Chris@41: get very, very close. Chris@41:

Chris@41:

Chris@41: In order to resample correctly (ie using the SRC_SINC_* converters), Chris@41: filtering needs to be applied, regardless of whether its upsampling or Chris@41: downsampling. Chris@41: This filter needs to attenuate all frequencies above 0.5 times the minimum of Chris@41: the source and destination sample rate (call this fshmin). Chris@41: Since the filter needed to achieve full attenuation at this point, it has to Chris@41: start rolling off a some frequency below this point. Chris@41: It is this rolloff of the very highest frequencies which causes some of the Chris@41: loss. Chris@41:

Chris@41:

Chris@41: The other factor is that the filter itself can introduce transient artifacts Chris@41: which causes the output to be different to the input. Chris@41:

Chris@41: Chris@41: Chris@41: Chris@41: Chris@41:

Q4 : If I ran src_simple on small chunks (say 160 frames) would that Chris@41: sound bad?

Chris@41:

Chris@41: Well if you are after odd sound effects, it might sound OK. Chris@41: If you are after high quality sample rate conversion you will be disappointed. Chris@41:

Chris@41:

Chris@41: The src_simple() was designed to provide a simple to use interface for people Chris@41: who wanted to do sample rate conversion on say, a whole file all at once. Chris@41:

Chris@41: Chris@41: Chris@41: Chris@41: Chris@41:

Q5 : I'm using libsamplerate but the high quality settings Chris@41: sound worse than the SRC_LINEAR converter. Why?

Chris@41:

Chris@41: There are two possible problems. Chris@41: Firstly, if you are using the src_simple() function on successive blocks Chris@41: of a stream of samples, you will get bad results. The src_simple() function Chris@41: is designed for use on a whole sound file, all at once, not on contiguous Chris@41: segments of the same sound file. Chris@41: To fix the problem, you need to move to the src_process() API or the callback Chris@41: based API. Chris@41:

Chris@41:

Chris@41: If you are already using the src_process() API or the callback based API and Chris@41: the high quality settings sound worse than SRC_LINEAR, then you have other Chris@41: problems. Chris@41: Read on for more debugging hints. Chris@41:

Chris@41:

Chris@41: All of the higher quality converters need to keep state while doing conversions Chris@41: on segments of a large chunk of audio. Chris@41: This state information is kept inside the private data pointed to by the Chris@41: SRC_STATE pointer returned by the src_new() function. Chris@41: This means, that when you want to start doing sample rate conversion on a Chris@41: stream of data, you should call src_new() to get a new SRC_STATE pointer Chris@41: (or alternatively, call src_reset() on an existing SRC_STATE pointer). Chris@41: You should then pass this SRC_STATE pointer to the src_process() function Chris@41: with each new block of audio data. Chris@41: When you have completed the conversion, you can then call src_delete() on Chris@41: the SRC_STATE pointer. Chris@41:

Chris@41:

Chris@41: If you are doing all of the above correctly, you need to examine your usage Chris@41: of the values passed to src_process() in the Chris@41: SRC_DATA Chris@41: struct. Chris@41: Specifically: Chris@41:

Chris@41:

Check that input_frames and output_frames fields are being set in Chris@41: terms of frames (number of sample values times channels) instead Chris@41: of just the number of samples. Chris@41:
Check that you are using the return values input_frames_used and Chris@41: output_frames_gen to update your source and destination pointers Chris@41: correctly. Chris@41:
Check that you are updating the data_in and data_out pointers Chris@41: correctly for each successive call. Chris@41:

Chris@41:

Chris@41: While doing the above, it is probably useful to compare what you are doing to Chris@41: what is done in the example programs in the examples/ directory of the source Chris@41: code tarball. Chris@41:

Chris@41:

Chris@41: If you have done all of the above and are still having problems then its Chris@41: probably time to email the author with the smallest chunk of code that Chris@41: adequately demonstrates your problem. Chris@41: This chunk should not need to be any more than 100 lines of code. Chris@41:

Chris@41: Chris@41: Chris@41: Chris@41: Chris@41:

Q6 : I'm use the SRC_SINC_* converters and up-sampling by a ratio of Chris@41: 2. I reset the converter and put in 1000 samples and I expect to get 2000 Chris@41: samples out, but I'm getting less than that. Why?

Chris@41:

Chris@41: The short answer is that there is a transport delay inside the converter itself. Chris@41: Long answer follows. Chris@41:

Chris@41:

Chris@41: By way of example, the first time you call src_process() you might only get 1900 Chris@41: samples out. Chris@41: However, after that first call all subsequent calls will probably get you about Chris@41: 2000 samples out for every 1000 samples you put in. Chris@41:

Chris@41:

Chris@41: The main problems people have with this transport delay is that they need to read Chris@41: out an exact number of samples and the transport delay scews this up. Chris@41: The best way to overcome this problem is to always supply more samples on the Chris@41: input than is actually needed to create the required number of output samples. Chris@41: With reference to the example above, if you always supply 1500 samples at the Chris@41: input, you will always get 2000 samples at the output. Chris@41: You will always need to keep track of the number of input frames used on each Chris@41: call to src_process() and deal with these values appropriately. Chris@41:

Chris@41: Chris@41: Chris@41: Chris@41: Chris@41:

Q7 : I have input and output sample rates that are integer Chris@41: values, but the API wants me to divide one by the other and put the result Chris@41: in a floating point number. Won't this case problems for long running Chris@41: conversions?

Chris@41:

Chris@41: The short answer is no, the precision of the ratio is many orders of magnitude Chris@41: more than is really needed. Chris@41:

Chris@41:

Chris@41: For the long answer, lets do come calculations. Chris@41: Firstly, the src_ratio field is double precision floating point number Chris@41: which has Chris@41: Chris@41: 53 bits of precision. Chris@41:

Chris@41:

Chris@41: That means that the maximum error in your ratio converted to a double is one Chris@41: bit in 2^53 which means the the double float value would be wrong by one sample Chris@41: after 9007199254740992 samples have passed or wrong by more than half a sample Chris@41: wrong after half that many (4503599627370496 samples) have passed. Chris@41:

Chris@41:

Chris@41: Now if for example our output sample rate is 96kHz then Chris@41:

Chris@41:

Chris@41:     4503599627370496 samples at 96kHz is 46912496118 seconds
Chris@41:     46912496118 seconds is 781874935 minutes
Chris@41:     781874935 minutes is 13031248 hours
Chris@41:     13031248 hours is 542968 days
Chris@41:     542968 days is 1486 years
Chris@41:

Chris@41:

Chris@41: So, after 1486 years, the input will be wrong by more than half of one sampling Chris@41: period. Chris@41:

Chris@41:

Chris@41: All this assumes that the crystal oscillators uses to sample the audio stream Chris@41: is perfect. Chris@41: This is not the case. Chris@41: According to Chris@41: Chris@41: this web site, Chris@41: the accuracy of standard crystal oscillators (XO, TCXO, OCXO) is at best Chris@41: 1 in 100 million. Chris@41: The src_ratio is therefore 45035996 times more accurate than the Chris@41: crystal clock source used to sample the original audio signal and any potential Chris@41: problem with the src_ratio being a floating point number will be Chris@41: completely swamped by sampling inaccuracies. Chris@41:

Chris@41: Chris@41: Chris@41: Chris@41: