[audio-libsamplerate.git] / libsamplerate / doc / faq.html

<!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>
Commit	Line	Data
	1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
	2	<HTML>
	3
	4	<HEAD>
	5	<TITLE>
	6	Secret Rabbit Code (aka libsamplerate)
	7	</TITLE>
	8	<META NAME="Author" CONTENT="Erik de Castro Lopo (erikd AT mega-nerd DOT com)">
	9	<META NAME="Version" CONTENT="libsamplerate-0.1.8">
	10	<META NAME="Description" CONTENT="The Secret Rabbit Code Home Page">
	11	<META NAME="Keywords" CONTENT="libsamplerate sound resample audio dsp Linux">
	12	<LINK REL=StyleSheet HREF="SRC.css" TYPE="text/css" MEDIA="all">
	13	</HEAD>
	14
	15	<BODY TEXT="#FFFFFF" BGCOLOR="#000000" LINK="#FB1465" VLINK="#FB1465" ALINK="#FB1465">
	16	<!-- pepper -->
	17	<CENTER>
	18	<IMG SRC="SRC.png" HEIGHT=100 WIDTH=760 ALT="SRC.png">
	19	</CENTER>
	20	<!-- pepper -->
	21	<BR>
	22	<!-- pepper -->
	23	<TABLE ALIGN="center" WIDTH="98%">
	24	<TR>
	25	<TD VALIGN="top">
	26	<BR>
	27	<DIV CLASS="nav">
	28	<BR>
	29	<A HREF="index.html">Home</A><BR>
	30	<A HREF="license.html">License</A><BR>
	31	<A HREF="history.html">History</A><BR>
	32	<A HREF="download.html">Download</A><BR>
	33	<A HREF="quality.html">Quality</A><BR>
	34	<A HREF="api.html">API</A><BR>
	35	<A HREF="bugs.html">Bug Reporting</A><BR>
	36	<A HREF="win32.html">On Win32</A><BR>
	37	<A HREF="faq.html">FAQ</A><BR>
	38	<A HREF="lists.html">Mailing Lists</A><BR>
	39	<A HREF="ChangeLog">ChangeLog</A><BR>
	40	<BR>
	41	<DIV CLASS="block">
	42	Author :<BR>Erik de Castro Lopo
	43	<!-- pepper -->
	44	<BR><BR>
	45	<!-- pepper -->
	46
	47	</DIV>
	48	<IMG SRC=
	49	"/cgi-bin/Count.cgi?ft=6\|frgb=55;55;55\|tr=0\|md=6\|dd=B\|st=1\|sh=1\|df=src_api.dat"
	50	HEIGHT=30 WIDTH=100 ALT="counter.gif">
	51	</DIV>
	52
	53	</TD>
	54	<!-- pepper -->
	55	<!-- ######################################################################## -->
	56	<!-- pepper -->
	57	<TD VALIGN="top">
	58	<DIV CLASS="block">
	59
	60	<H1><B>Frequently Asked Questions</B></H1>
	61	<P>
	62	<A HREF="#Q001">Q1 : Is it normal for the output of libsamplerate to be louder
	63	than its input?</A><BR><BR>
	64	<A HREF="#Q002">Q2 : On Unix/Linux/MacOSX, what is the best way of detecting
	65	the presence and location of libsamplerate and its header file using
	66	autoconf?</A><BR><BR>
	67	<A HREF="#Q003">Q3 : If I upsample and downsample to the original rate, for
	68	example 44.1->96->44.1, do I get an identical signal as the one before the
	69	up/down resampling?</A><BR><BR>
	70	<A HREF="#Q004">Q4 : If I ran src_simple (libsamplerate) on small chunks (160
	71	frames) would that sound bad?</A><BR><BR>
	72	<A HREF="#Q005">Q5 : I'm using libsamplerate but the high quality settings
	73	sound worse than the SRC_LINEAR converter. Why?</A><BR><BR>
	74	<A HREF="#Q006">Q6 : I'm use the SRC_SINC_* converters and up-sampling by a ratio of
	75	2. I reset the converter and put in 1000 samples and I expect to get 2000
	76	samples out, but I'm getting less than that. Why?</A><BR><BR>
	77	<A HREF="#Q007">Q7 : I have input and output sample rates that are integer
	78	values, but the API wants me to divide one by the other and put the result
	79	in a floating point number. Won't this case problems for long running
	80	conversions?</A><BR><BR>
	81	</P>
	82	<HR>
	83	<!-- ========================================================================= -->
	84	<A NAME="Q001"></A>
	85	<H2><BR><B>Q1 : Is it normal for the output of libsamplerate to be louder
	86	than its input?</B></H2>
	87	<P>
	88	The output of libsamplerate will be roughly the same volume as the input.
	89	However, even if the input is strictly in the range (-1.0, 1.0), it is still
	90	possible for the output to contain peak values outside this range.
	91	</P>
	92	<P>
	93	Consider four consecutive samples of [0.5 0.999 0.999 0.5].
	94	If we are up sampling by a factor of two we need to insert samples between
	95	each of the existing samples.
	96	Its pretty obvious then, that the sample between the two 0.999 values should
	97	and will be bigger than 0.999.
	98	</P>
	99	<P>
	100	This means that anyone using libsamplerate should normalize its output before
	101	doing things like saving the audio to a 16 bit WAV file.
	102	</P>
	103
	104	<!-- pepper -->
	105	<!-- ========================================================================= -->
	106
	107	<a NAME="Q002"></a>
	108	<h2><br><b>Q2 : On Unix/Linux/MacOSX, what is the best way of detecting
	109	the presence and location of libsamplerate and its header file using
	110	autoconf?</b></h2>
	111
	112	<p>
	113	libsamplerate uses the pkg-config (man pkg-config) method of registering itself
	114	with the host system.
	115	The best way of detecting its presence is using something like this in configure.ac
	116	(or configure.in):
	117	</p>
	118
	119	<pre>
	120	PKG_CHECK_MODULES(SAMPLERATE, samplerate >= 0.1.3,
	121	ac_cv_samplerate=1, ac_cv_samplerate=0)
	122
	123	AC_DEFINE_UNQUOTED([HAVE_SAMPLERATE],${ac_cv_samplerate},
	124	[Set to 1 if you have libsamplerate.])
	125
	126	AC_SUBST(SAMPLERATE_CFLAGS)
	127	AC_SUBST(SAMPLERATE_LIBS)
	128	</pre>
	129	<p>
	130	This will automatically set the <b>SAMPLERATE_CFLAGS</b> and <b>SAMPLERATE_LIBS</b>
	131	variables which can be used in Makefile.am or Makefile.in like this:
	132	</p>
	133	<pre>
	134	SAMPLERATE_CFLAGS = @SAMPLERATE_CFLAGS@
	135	SAMPLERATE_LIBS = @SAMPLERATE_LIBS@
	136	</pre>
	137
	138	<p>
	139	If you install libsamplerate from source, you will probably need to set the
	140	<b>PKG_CONFIG_PATH</b> environment variable's suggested at the end of the
	141	libsamplerate configure process. For instance on my system I get this:
	142	</p>
	143	<pre>
	144	-=-=-=-=-=-=-=-=-=-= Configuration Complete =-=-=-=-=-=-=-=-=-=-=-
	145
	146	Configuration summary :
	147
	148	Version : ..................... 0.1.3
	149	Enable debugging : ............ no
	150
	151	Tools :
	152
	153	Compiler is GCC : ............. yes
	154	GCC major version : ........... 3
	155
	156	Extra tools required for testing and examples :
	157
	158	Have FFTW : ................... yes
	159	Have libsndfile : ............. yes
	160	Have libefence : .............. no
	161
	162	Installation directories :
	163
	164	Library directory : ........... /usr/local/lib
	165	Program directory : ........... /usr/local/bin
	166	Pkgconfig directory : ......... /usr/local/lib/pkgconfig
	167	</pre>
	168
	169
	170	<!-- pepper -->
	171	<!-- ========================================================================= -->
	172	<A NAME="Q003"></A>
	173	<H2><BR><B>Q3 : If I upsample and downsample to the original rate, for
	174	example 44.1->96->44.1, do I get an identical signal as the one before the
	175	up/down resampling?</B></H2>
	176	<P>
	177	The short answer is that for the general case, no, you don't.
	178	The long answer is that for some signals, with some converters, you will
	179	get very, very close.
	180	</P>
	181	<P>
	182	In order to resample correctly (ie using the <B>SRC_SINC_*</B> converters),
	183	filtering needs to be applied, regardless of whether its upsampling or
	184	downsampling.
	185	This filter needs to attenuate all frequencies above 0.5 times the minimum of
	186	the source and destination sample rate (call this fshmin).
	187	Since the filter needed to achieve full attenuation at this point, it has to
	188	start rolling off a some frequency below this point.
	189	It is this rolloff of the very highest frequencies which causes some of the
	190	loss.
	191	</P>
	192	<P>
	193	The other factor is that the filter itself can introduce transient artifacts
	194	which causes the output to be different to the input.
	195	</P>
	196
	197	<!-- pepper -->
	198	<!-- ========================================================================= -->
	199	<A NAME="Q004"></A>
	200	<H2><BR><B>Q4 : If I ran src_simple on small chunks (say 160 frames) would that
	201	sound bad?</B></H2>
	202	<P>
	203	Well if you are after odd sound effects, it might sound OK.
	204	If you are after high quality sample rate conversion you will be disappointed.
	205	</P>
	206	<P>
	207	The src_simple() was designed to provide a simple to use interface for people
	208	who wanted to do sample rate conversion on say, a whole file all at once.
	209	</P>
	210
	211	<!-- pepper -->
	212	<!-- ========================================================================= -->
	213	<A NAME="Q005"></A>
	214	<H2><BR><B>Q5 : I'm using libsamplerate but the high quality settings
	215	sound worse than the SRC_LINEAR converter. Why?</B></H2>
	216	<P>
	217	There are two possible problems.
	218	Firstly, if you are using the src_simple() function on successive blocks
	219	of a stream of samples, you will get bad results. The src_simple() function
	220	is designed for use on a whole sound file, all at once, not on contiguous
	221	segments of the same sound file.
	222	To fix the problem, you need to move to the src_process() API or the callback
	223	based API.
	224	</P>
	225	<P>
	226	If you are already using the src_process() API or the callback based API and
	227	the high quality settings sound worse than SRC_LINEAR, then you have other
	228	problems.
	229	Read on for more debugging hints.
	230	</P>
	231	<P>
	232	All of the higher quality converters need to keep state while doing conversions
	233	on segments of a large chunk of audio.
	234	This state information is kept inside the private data pointed to by the
	235	SRC_STATE pointer returned by the src_new() function.
	236	This means, that when you want to start doing sample rate conversion on a
	237	stream of data, you should call src_new() to get a new SRC_STATE pointer
	238	(or alternatively, call src_reset() on an existing SRC_STATE pointer).
	239	You should then pass this SRC_STATE pointer to the src_process() function
	240	with each new block of audio data.
	241	When you have completed the conversion, you can then call src_delete() on
	242	the SRC_STATE pointer.
	243	</P>
	244	<P>
	245	If you are doing all of the above correctly, you need to examine your usage
	246	of the values passed to src_process() in the
	247	<A HREF="api_misc.html#SRC_DATA">SRC_DATA</A>
	248	struct.
	249	Specifically:
	250	</P>
	251	<UL>
	252	<LI> Check that input_frames and output_frames fields are being set in
	253	terms of frames (number of sample values times channels) instead
	254	of just the number of samples.
	255	<LI> Check that you are using the return values input_frames_used and
	256	output_frames_gen to update your source and destination pointers
	257	correctly.
	258	<LI> Check that you are updating the data_in and data_out pointers
	259	correctly for each successive call.
	260	</UL>
	261	<P>
	262	While doing the above, it is probably useful to compare what you are doing to
	263	what is done in the example programs in the examples/ directory of the source
	264	code tarball.
	265	</P>
	266	<P>
	267	If you have done all of the above and are still having problems then its
	268	probably time to email the author with the smallest chunk of code that
	269	adequately demonstrates your problem.
	270	This chunk should not need to be any more than 100 lines of code.
	271	</P>
	272
	273	<!-- pepper -->
	274	<!-- ========================================================================= -->
	275	<A NAME="Q006"></A>
	276	<H2><BR><B>Q6 : I'm use the SRC_SINC_* converters and up-sampling by a ratio of
	277	2. I reset the converter and put in 1000 samples and I expect to get 2000
	278	samples out, but I'm getting less than that. Why?</B></H2>
	279	<P>
	280	The short answer is that there is a transport delay inside the converter itself.
	281	Long answer follows.
	282	</P>
	283	<P>
	284	By way of example, the first time you call src_process() you might only get 1900
	285	samples out.
	286	However, after that first call all subsequent calls will probably get you about
	287	2000 samples out for every 1000 samples you put in.
	288	</P>
	289	<P>
	290	The main problems people have with this transport delay is that they need to read
	291	out an exact number of samples and the transport delay scews this up.
	292	The best way to overcome this problem is to always supply more samples on the
	293	input than is actually needed to create the required number of output samples.
	294	With reference to the example above, if you always supply 1500 samples at the
	295	input, you will always get 2000 samples at the output.
	296	You will always need to keep track of the number of input frames used on each
	297	call to src_process() and deal with these values appropriately.
	298	</P>
	299
	300	<!-- pepper -->
	301	<!-- ========================================================================= -->
	302	<A NAME="Q007"></A>
	303	<H2><BR><B>Q7 : I have input and output sample rates that are integer
	304	values, but the API wants me to divide one by the other and put the result
	305	in a floating point number. Won't this case problems for long running
	306	conversions?</B></H2>
	307	<P>
	308	The short answer is no, the precision of the ratio is many orders of magnitude
	309	more than is really needed.
	310	</P>
	311	<P>
	312	For the long answer, lets do come calculations.
	313	Firstly, the <tt>src_ratio</tt> field is double precision floating point number
	314	which has
	315	<a href="http://en.wikipedia.org/wiki/Double_precision">
	316	53 bits of precision</a>.
	317	</P>
	318	<P>
	319	That means that the maximum error in your ratio converted to a double is one
	320	bit in 2^53 which means the the double float value would be wrong by one sample
	321	after 9007199254740992 samples have passed or wrong by more than half a sample
	322	wrong after half that many (4503599627370496 samples) have passed.
	323	</P>
	324	<P>
	325	Now if for example our output sample rate is 96kHz then
	326	</P>
	327	<pre>
	328	4503599627370496 samples at 96kHz is 46912496118 seconds
	329	46912496118 seconds is 781874935 minutes
	330	781874935 minutes is 13031248 hours
	331	13031248 hours is 542968 days
	332	542968 days is 1486 years
	333	</pre>
	334	<P>
	335	So, after 1486 years, the input will be wrong by more than half of one sampling
	336	period.
	337	</P>
	338	<p>
	339	All this assumes that the crystal oscillators uses to sample the audio stream
	340	is perfect.
	341	This is not the case.
	342	According to
	343	<a href="http://www.ieee-uffc.org/freqcontrol/quartz/vig/vigcomp.htm">
	344	this web site</a>,
	345	the accuracy of standard crystal oscillators (XO, TCXO, OCXO) is at best
	346	1 in 100 million.
	347	The <tt>src_ratio</tt> is therefore 45035996 times more accurate than the
	348	crystal clock source used to sample the original audio signal and any potential
	349	problem with the <tt>src_ratio</tt> being a floating point number will be
	350	completely swamped by sampling inaccuracies.
	351	</p>
	352
	353	<!-- <A HREF="mailto:aldel@mega-nerd.com">For the spam bots</A> -->
	354
	355	</DIV>
	356	</TD></TR>
	357	</TABLE>
	358
	359	</BODY>
	360	</HTML>
	361