← Back to branch summary

~ubuntu-branches/ubuntu/quantal/libsamplerate/quantal

« back to all changes in this revision

Viewing changes to doc/faq.html

  • Committer: Bazaar Package Importer
  • Author(s): Samuel Mimram
  • Date: 2009-02-17 23:35:15 UTC
  • mfrom: (1.1.5 upstream) (4.1.2 squeeze)
  • Revision ID: james.westby@ubuntu.com-20090217233515-vblyud7n95kj76u5
Tags: 0.1.7-2
http://bugs.debian.org/515658
Added callback_test.dpatch to correct rounding error in callback test,
closes: #515658.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/faq.html
6
6
        Secret Rabbit Code (aka libsamplerate)
7
7
        </TITLE>
8
8
        <META NAME="Author"      CONTENT="Erik de Castro Lopo (erikd AT mega-nerd DOT com)">
9
 
    <META NAME="Version"     CONTENT="libsamplerate-0.1.4">
 
9
    <META NAME="Version"     CONTENT="libsamplerate-0.1.7">
10
10
        <META NAME="Description" CONTENT="The Secret Rabbit Code Home Page">
11
11
        <META NAME="Keywords"    CONTENT="libsamplerate sound resample audio dsp Linux">
12
12
        <LINK REL=StyleSheet HREF="SRC.css" TYPE="text/css" MEDIA="all">
74
74
<A HREF="#Q006">Q6 : I'm use the SRC_SINC_* converters and up-sampling by a ratio of 
75
75
        2. I reset the converter and put in 1000 samples and I expect to get 2000
76
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>
77
81
</P>
78
82
<HR>
79
83
<!-- ========================================================================= -->
97
101
doing things like saving the audio to a 16 bit WAV file.
98
102
</P>
99
103
 
 
104
<!-- pepper -->
100
105
<!-- ========================================================================= -->
101
106
 
102
107
<a NAME="Q002"></a>
112
117
</p>
113
118
 
114
119
<pre>
115
 
    PKG_CHECK_MODULES(SAMPLERATE, samplerate >= 0.0.15,
 
120
    PKG_CHECK_MODULES(SAMPLERATE, samplerate >= 0.1.3,
116
121
            ac_cv_samplerate=1, ac_cv_samplerate=0)
117
122
 
118
123
    AC_DEFINE_UNQUOTED([HAVE_SAMPLERATE],${ac_cv_samplerate},
140
145
 
141
146
      Configuration summary :
142
147
 
143
 
        Version : ..................... 0.1.0
 
148
        Version : ..................... 0.1.3
144
149
        Enable debugging : ............ no
145
150
 
146
151
      Tools :
162
167
</pre>
163
168
 
164
169
 
 
170
<!-- pepper -->
165
171
<!-- ========================================================================= -->
166
172
<A NAME="Q003"></A>
167
173
<H2><BR><B>Q3 : If I upsample and downsample to the original rate, for
188
194
which causes the output to be different to the input.
189
195
</P>
190
196
 
 
197
<!-- pepper -->
191
198
<!-- ========================================================================= -->
192
199
<A NAME="Q004"></A>
193
200
<H2><BR><B>Q4 : If I ran src_simple on small chunks (say 160 frames) would that
201
208
who wanted to do sample rate conversion on say, a whole file all at once.
202
209
</P>
203
210
 
 
211
<!-- pepper -->
204
212
<!-- ========================================================================= -->
205
213
<A NAME="Q005"></A>
206
214
<H2><BR><B>Q5 : I'm using libsamplerate but the high quality settings
262
270
This chunk should not need to be any more than 100 lines of code.
263
271
</P>
264
272
 
 
273
<!-- pepper -->
265
274
<!-- ========================================================================= -->
266
275
<A NAME="Q006"></A>
267
276
<H2><BR><B>Q6 : I'm use the SRC_SINC_* converters and up-sampling by a ratio of 
288
297
call to src_process() and deal with these values appropriately.
289
298
</P>
290
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
 
291
353
<!-- <A HREF="mailto:aldel@mega-nerd.com">For the spam bots</A> -->
292
354
 
293
355
</DIV>