| @@ -74,6 +74,10 @@ Author :<BR>Erik de Castro Lopo · 73 unmodified lines |
| 74 | <A HREF="#Q006">Q6 : I'm use the SRC_SINC_* converters and up-sampling by a ratio of | 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 | 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> | 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 | </P> | 81 | </P> |
| 78 | <HR> | 82 | <HR> |
| 79 | <!-- ========================================================================= --> | 83 | <!-- ========================================================================= --> |
| @@ -97,6 +101,7 @@ This means that anyone using libsamplerate should normalize its output before · 17 unmodified lines |
| 97 | doing things like saving the audio to a 16 bit WAV file. | 101 | doing things like saving the audio to a 16 bit WAV file. |
| 98 | </P> | 102 | </P> |
| 99 | | 103 | |
| | 104 | <!-- pepper --> |
| 100 | <!-- ========================================================================= --> | 105 | <!-- ========================================================================= --> |
| 101 | | 106 | |
| 102 | <a NAME="Q002"></a> | 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 | </p> | 117 | </p> |
| 113 | | 118 | |
| 114 | <pre> | 119 | <pre> |
| 115 | PKG_CHECK_MODULES(SAMPLERATE, samplerate >= 0.0.15, | 120 | PKG_CHECK_MODULES(SAMPLERATE, samplerate >= 0.1.3, |
| 116 | ac_cv_samplerate=1, ac_cv_samplerate=0) | 121 | ac_cv_samplerate=1, ac_cv_samplerate=0) |
| 117 | | 122 | |
| 118 | AC_DEFINE_UNQUOTED([HAVE_SAMPLERATE],${ac_cv_samplerate}, | 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 | Configuration summary : | 146 | Configuration summary : |
| 142 | | 147 | |
| 143 | Version : ..................... 0.1.0 | 148 | Version : ..................... 0.1.3 |
| 144 | Enable debugging : ............ no | 149 | Enable debugging : ............ no |
| 145 | | 150 | |
| 146 | Tools : | 151 | Tools : |
| @@ -162,6 +167,7 @@ libsamplerate configure process. For instance on my system I get this: · 15 unmodified lines |
| 162 | </pre> | 167 | </pre> |
| 163 | | 168 | |
| 164 | | 169 | |
| | 170 | <!-- pepper --> |
| 165 | <!-- ========================================================================= --> | 171 | <!-- ========================================================================= --> |
| 166 | <A NAME="Q003"></A> | 172 | <A NAME="Q003"></A> |
| 167 | <H2><BR><B>Q3 : If I upsample and downsample to the original rate, for | 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 | which causes the output to be different to the input. | 194 | which causes the output to be different to the input. |
| 189 | </P> | 195 | </P> |
| 190 | | 196 | |
| | 197 | <!-- pepper --> |
| 191 | <!-- ========================================================================= --> | 198 | <!-- ========================================================================= --> |
| 192 | <A NAME="Q004"></A> | 199 | <A NAME="Q004"></A> |
| 193 | <H2><BR><B>Q4 : If I ran src_simple on small chunks (say 160 frames) would that | 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 | who wanted to do sample rate conversion on say, a whole file all at once. | 208 | who wanted to do sample rate conversion on say, a whole file all at once. |
| 202 | </P> | 209 | </P> |
| 203 | | 210 | |
| | 211 | <!-- pepper --> |
| 204 | <!-- ========================================================================= --> | 212 | <!-- ========================================================================= --> |
| 205 | <A NAME="Q005"></A> | 213 | <A NAME="Q005"></A> |
| 206 | <H2><BR><B>Q5 : I'm using libsamplerate but the high quality settings | 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 | This chunk should not need to be any more than 100 lines of code. | 270 | This chunk should not need to be any more than 100 lines of code. |
| 263 | </P> | 271 | </P> |
| 264 | | 272 | |
| | 273 | <!-- pepper --> |
| 265 | <!-- ========================================================================= --> | 274 | <!-- ========================================================================= --> |
| 266 | <A NAME="Q006"></A> | 275 | <A NAME="Q006"></A> |
| 267 | <H2><BR><B>Q6 : I'm use the SRC_SINC_* converters and up-sampling by a ratio of | 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 | call to src_process() and deal with these values appropriately. | 297 | call to src_process() and deal with these values appropriately. |
| 289 | </P> | 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 | <!-- <A HREF="mailto:aldel@mega-nerd.com">For the spam bots</A> --> | 353 | <!-- <A HREF="mailto:aldel@mega-nerd.com">For the spam bots</A> --> |
| 292 | | 354 | |
| 293 | </DIV> | 355 | </DIV> |