| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| <HTML> |
| |
| <HEAD> |
| <TITLE> |
| Secret Rabbit Code (aka libsamplerate) |
| </TITLE> |
| <META NAME="Author" CONTENT="Erik de Castro Lopo (erikd AT mega-nerd DOT com)"> |
| <META NAME="Version" CONTENT="libsamplerate-0.1.8"> |
| <META NAME="Description" CONTENT="The Secret Rabbit Code Home Page"> |
| <META NAME="Keywords" CONTENT="libsamplerate sound resample audio dsp Linux"> |
| <LINK REL=StyleSheet HREF="SRC.css" TYPE="text/css" MEDIA="all"> |
| </HEAD> |
| |
| <BODY TEXT="#FFFFFF" BGCOLOR="#000000" LINK="#FB1465" VLINK="#FB1465" ALINK="#FB1465"> |
| <!-- pepper --> |
| <CENTER> |
| <IMG SRC="SRC.png" HEIGHT=100 WIDTH=760 ALT="SRC.png"> |
| </CENTER> |
| <!-- pepper --> |
| <BR> |
| <!-- pepper --> |
| <TABLE ALIGN="center" WIDTH="98%"> |
| <TR> |
| <TD VALIGN="top"> |
| <BR> |
| <DIV CLASS="nav"> |
| <BR> |
| <A HREF="index.html">Home</A><BR> |
| <A HREF="license.html">License</A><BR> |
| <A HREF="history.html">History</A><BR> |
| <A HREF="download.html">Download</A><BR> |
| <A HREF="quality.html">Quality</A><BR> |
| <A HREF="api.html">API</A><BR> |
| <A HREF="bugs.html">Bug Reporting</A><BR> |
| <A HREF="win32.html">On Win32</A><BR> |
| <A HREF="faq.html">FAQ</A><BR> |
| <A HREF="lists.html">Mailing Lists</A><BR> |
| <A HREF="ChangeLog">ChangeLog</A><BR> |
| <BR> |
| <DIV CLASS="block"> |
| Author :<BR>Erik de Castro Lopo |
| <!-- pepper --> |
| <BR><BR> |
| <!-- pepper --> |
| |
| </DIV> |
| <IMG SRC= |
| "/cgi-bin/Count.cgi?ft=6|frgb=55;55;55|tr=0|md=6|dd=B|st=1|sh=1|df=src_api.dat" |
| HEIGHT=30 WIDTH=100 ALT="counter.gif"> |
| </DIV> |
| |
| </TD> |
| <!-- pepper --> |
| <!-- ######################################################################## --> |
| <!-- pepper --> |
| <TD VALIGN="top"> |
| <DIV CLASS="block"> |
| |
| <H1><B>Frequently Asked Questions</B></H1> |
| <P> |
| <A HREF="#Q001">Q1 : Is it normal for the output of libsamplerate to be louder |
| than its input?</A><BR><BR> |
| <A HREF="#Q002">Q2 : On Unix/Linux/MacOSX, what is the best way of detecting |
| the presence and location of libsamplerate and its header file using |
| autoconf?</A><BR><BR> |
| <A HREF="#Q003">Q3 : If I upsample and downsample to the original rate, for |
| example 44.1->96->44.1, do I get an identical signal as the one before the |
| up/down resampling?</A><BR><BR> |
| <A HREF="#Q004">Q4 : If I ran src_simple (libsamplerate) on small chunks (160 |
| frames) would that sound bad?</A><BR><BR> |
| <A HREF="#Q005">Q5 : I'm using libsamplerate but the high quality settings |
| sound worse than the SRC_LINEAR converter. Why?</A><BR><BR> |
| <A HREF="#Q006">Q6 : I'm use the SRC_SINC_* converters and up-sampling by a ratio of |
| 2. I reset the converter and put in 1000 samples and I expect to get 2000 |
| samples out, but I'm getting less than that. Why?</A><BR><BR> |
| <A HREF="#Q007">Q7 : I have input and output sample rates that are integer |
| values, but the API wants me to divide one by the other and put the result |
| in a floating point number. Won't this case problems for long running |
| conversions?</A><BR><BR> |
| </P> |
| <HR> |
| <!-- ========================================================================= --> |
| <A NAME="Q001"></A> |
| <H2><BR><B>Q1 : Is it normal for the output of libsamplerate to be louder |
| than its input?</B></H2> |
| <P> |
| The output of libsamplerate will be roughly the same volume as the input. |
| However, even if the input is strictly in the range (-1.0, 1.0), it is still |
| possible for the output to contain peak values outside this range. |
| </P> |
| <P> |
| Consider four consecutive samples of [0.5 0.999 0.999 0.5]. |
| If we are up sampling by a factor of two we need to insert samples between |
| each of the existing samples. |
| Its pretty obvious then, that the sample between the two 0.999 values should |
| and will be bigger than 0.999. |
| </P> |
| <P> |
| This means that anyone using libsamplerate should normalize its output before |
| doing things like saving the audio to a 16 bit WAV file. |
| </P> |
| |
| <!-- pepper --> |
| <!-- ========================================================================= --> |
| |
| <a NAME="Q002"></a> |
| <h2><br><b>Q2 : On Unix/Linux/MacOSX, what is the best way of detecting |
| the presence and location of libsamplerate and its header file using |
| autoconf?</b></h2> |
| |
| <p> |
| libsamplerate uses the pkg-config (man pkg-config) method of registering itself |
| with the host system. |
| The best way of detecting its presence is using something like this in configure.ac |
| (or configure.in): |
| </p> |
| |
| <pre> |
| PKG_CHECK_MODULES(SAMPLERATE, samplerate >= 0.1.3, |
| ac_cv_samplerate=1, ac_cv_samplerate=0) |
| |
| AC_DEFINE_UNQUOTED([HAVE_SAMPLERATE],${ac_cv_samplerate}, |
| [Set to 1 if you have libsamplerate.]) |
| |
| AC_SUBST(SAMPLERATE_CFLAGS) |
| AC_SUBST(SAMPLERATE_LIBS) |
| </pre> |
| <p> |
| This will automatically set the <b>SAMPLERATE_CFLAGS</b> and <b>SAMPLERATE_LIBS</b> |
| variables which can be used in Makefile.am or Makefile.in like this: |
| </p> |
| <pre> |
| SAMPLERATE_CFLAGS = @SAMPLERATE_CFLAGS@ |
| SAMPLERATE_LIBS = @SAMPLERATE_LIBS@ |
| </pre> |
| |
| <p> |
| If you install libsamplerate from source, you will probably need to set the |
| <b>PKG_CONFIG_PATH</b> environment variable's suggested at the end of the |
| libsamplerate configure process. For instance on my system I get this: |
| </p> |
| <pre> |
| -=-=-=-=-=-=-=-=-=-= Configuration Complete =-=-=-=-=-=-=-=-=-=-=- |
| |
| Configuration summary : |
| |
| Version : ..................... 0.1.3 |
| Enable debugging : ............ no |
| |
| Tools : |
| |
| Compiler is GCC : ............. yes |
| GCC major version : ........... 3 |
| |
| Extra tools required for testing and examples : |
| |
| Have FFTW : ................... yes |
| Have libsndfile : ............. yes |
| Have libefence : .............. no |
| |
| Installation directories : |
| |
| Library directory : ........... /usr/local/lib |
| Program directory : ........... /usr/local/bin |
| Pkgconfig directory : ......... /usr/local/lib/pkgconfig |
| </pre> |
| |
| |
| <!-- pepper --> |
| <!-- ========================================================================= --> |
| <A NAME="Q003"></A> |
| <H2><BR><B>Q3 : If I upsample and downsample to the original rate, for |
| example 44.1->96->44.1, do I get an identical signal as the one before the |
| up/down resampling?</B></H2> |
| <P> |
| The short answer is that for the general case, no, you don't. |
| The long answer is that for some signals, with some converters, you will |
| get very, very close. |
| </P> |
| <P> |
| In order to resample correctly (ie using the <B>SRC_SINC_*</B> converters), |
| filtering needs to be applied, regardless of whether its upsampling or |
| downsampling. |
| This filter needs to attenuate all frequencies above 0.5 times the minimum of |
| the source and destination sample rate (call this fshmin). |
| Since the filter needed to achieve full attenuation at this point, it has to |
| start rolling off a some frequency below this point. |
| It is this rolloff of the very highest frequencies which causes some of the |
| loss. |
| </P> |
| <P> |
| The other factor is that the filter itself can introduce transient artifacts |
| which causes the output to be different to the input. |
| </P> |
| |
| <!-- pepper --> |
| <!-- ========================================================================= --> |
| <A NAME="Q004"></A> |
| <H2><BR><B>Q4 : If I ran src_simple on small chunks (say 160 frames) would that |
| sound bad?</B></H2> |
| <P> |
| Well if you are after odd sound effects, it might sound OK. |
| If you are after high quality sample rate conversion you will be disappointed. |
| </P> |
| <P> |
| The src_simple() was designed to provide a simple to use interface for people |
| who wanted to do sample rate conversion on say, a whole file all at once. |
| </P> |
| |
| <!-- pepper --> |
| <!-- ========================================================================= --> |
| <A NAME="Q005"></A> |
| <H2><BR><B>Q5 : I'm using libsamplerate but the high quality settings |
| sound worse than the SRC_LINEAR converter. Why?</B></H2> |
| <P> |
| There are two possible problems. |
| Firstly, if you are using the src_simple() function on successive blocks |
| of a stream of samples, you will get bad results. The src_simple() function |
| is designed for use on a whole sound file, all at once, not on contiguous |
| segments of the same sound file. |
| To fix the problem, you need to move to the src_process() API or the callback |
| based API. |
| </P> |
| <P> |
| If you are already using the src_process() API or the callback based API and |
| the high quality settings sound worse than SRC_LINEAR, then you have other |
| problems. |
| Read on for more debugging hints. |
| </P> |
| <P> |
| All of the higher quality converters need to keep state while doing conversions |
| on segments of a large chunk of audio. |
| This state information is kept inside the private data pointed to by the |
| SRC_STATE pointer returned by the src_new() function. |
| This means, that when you want to start doing sample rate conversion on a |
| stream of data, you should call src_new() to get a new SRC_STATE pointer |
| (or alternatively, call src_reset() on an existing SRC_STATE pointer). |
| You should then pass this SRC_STATE pointer to the src_process() function |
| with each new block of audio data. |
| When you have completed the conversion, you can then call src_delete() on |
| the SRC_STATE pointer. |
| </P> |
| <P> |
| If you are doing all of the above correctly, you need to examine your usage |
| of the values passed to src_process() in the |
| <A HREF="api_misc.html#SRC_DATA">SRC_DATA</A> |
| struct. |
| Specifically: |
| </P> |
| <UL> |
| <LI> Check that input_frames and output_frames fields are being set in |
| terms of frames (number of sample values times channels) instead |
| of just the number of samples. |
| <LI> Check that you are using the return values input_frames_used and |
| output_frames_gen to update your source and destination pointers |
| correctly. |
| <LI> Check that you are updating the data_in and data_out pointers |
| correctly for each successive call. |
| </UL> |
| <P> |
| While doing the above, it is probably useful to compare what you are doing to |
| what is done in the example programs in the examples/ directory of the source |
| code tarball. |
| </P> |
| <P> |
| If you have done all of the above and are still having problems then its |
| probably time to email the author with the smallest chunk of code that |
| adequately demonstrates your problem. |
| This chunk should not need to be any more than 100 lines of code. |
| </P> |
| |
| <!-- pepper --> |
| <!-- ========================================================================= --> |
| <A NAME="Q006"></A> |
| <H2><BR><B>Q6 : I'm use the SRC_SINC_* converters and up-sampling by a ratio of |
| 2. I reset the converter and put in 1000 samples and I expect to get 2000 |
| samples out, but I'm getting less than that. Why?</B></H2> |
| <P> |
| The short answer is that there is a transport delay inside the converter itself. |
| Long answer follows. |
| </P> |
| <P> |
| By way of example, the first time you call src_process() you might only get 1900 |
| samples out. |
| However, after that first call all subsequent calls will probably get you about |
| 2000 samples out for every 1000 samples you put in. |
| </P> |
| <P> |
| The main problems people have with this transport delay is that they need to read |
| out an exact number of samples and the transport delay scews this up. |
| The best way to overcome this problem is to always supply more samples on the |
| input than is actually needed to create the required number of output samples. |
| With reference to the example above, if you always supply 1500 samples at the |
| input, you will always get 2000 samples at the output. |
| You will always need to keep track of the number of input frames used on each |
| call to src_process() and deal with these values appropriately. |
| </P> |
| |
| <!-- pepper --> |
| <!-- ========================================================================= --> |
| <A NAME="Q007"></A> |
| <H2><BR><B>Q7 : I have input and output sample rates that are integer |
| values, but the API wants me to divide one by the other and put the result |
| in a floating point number. Won't this case problems for long running |
| conversions?</B></H2> |
| <P> |
| The short answer is no, the precision of the ratio is many orders of magnitude |
| more than is really needed. |
| </P> |
| <P> |
| For the long answer, lets do come calculations. |
| Firstly, the <tt>src_ratio</tt> field is double precision floating point number |
| which has |
| <a href="http://en.wikipedia.org/wiki/Double_precision"> |
| 53 bits of precision</a>. |
| </P> |
| <P> |
| That means that the maximum error in your ratio converted to a double is one |
| bit in 2^53 which means the the double float value would be wrong by one sample |
| after 9007199254740992 samples have passed or wrong by more than half a sample |
| wrong after half that many (4503599627370496 samples) have passed. |
| </P> |
| <P> |
| Now if for example our output sample rate is 96kHz then |
| </P> |
| <pre> |
| 4503599627370496 samples at 96kHz is 46912496118 seconds |
| 46912496118 seconds is 781874935 minutes |
| 781874935 minutes is 13031248 hours |
| 13031248 hours is 542968 days |
| 542968 days is 1486 years |
| </pre> |
| <P> |
| So, after 1486 years, the input will be wrong by more than half of one sampling |
| period. |
| </P> |
| <p> |
| All this assumes that the crystal oscillators uses to sample the audio stream |
| is perfect. |
| This is not the case. |
| According to |
| <a href="http://www.ieee-uffc.org/freqcontrol/quartz/vig/vigcomp.htm"> |
| this web site</a>, |
| the accuracy of standard crystal oscillators (XO, TCXO, OCXO) is at best |
| 1 in 100 million. |
| The <tt>src_ratio</tt> is therefore 45035996 times more accurate than the |
| crystal clock source used to sample the original audio signal and any potential |
| problem with the <tt>src_ratio</tt> being a floating point number will be |
| completely swamped by sampling inaccuracies. |
| </p> |
| |
| <!-- <A HREF="mailto:aldel@mega-nerd.com">For the spam bots</A> --> |
| |
| </DIV> |
| </TD></TR> |
| </TABLE> |
| |
| </BODY> |
| </HTML> |
| |