| @@ -74,6 +74,10 @@ Author :<BR>Erik de Castro Lopo · 73 unmodified lines |
| 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,6 +101,7 @@ This means that anyone using libsamplerate should normalize its output before · 17 unmodified lines |
| 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,7 +117,7 @@ The best way of detecting its presence is using something like this in configure · 9 unmodified lines |
| 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,7 +145,7 @@ libsamplerate configure process. For instance on my system I get this: · 21 unmodified lines |
| 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,6 +167,7 @@ libsamplerate configure process. For instance on my system I get this: · 15 unmodified lines |
| 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,6 +194,7 @@ The other factor is that the filter itself can introduce transient artifacts · 20 unmodified lines |
| 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,6 +208,7 @@ The src_simple() was designed to provide a simple to use interface for people · 7 unmodified lines |
| 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,6 +270,7 @@ adequately demonstrates your problem. · 55 unmodified lines |
| 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,6 +297,59 @@ You will always need to keep track of the number of input frames used on each · 20 unmodified lines |
| 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> |