My A/D samples at 33.33kHz and after processing I am using the sound card to output the audio result. The sound card only accepts 44.1khz, 22.05kHz etc. I am thinking of going 33.1 to 20.05. this doesn't have to be spot on, just approx since it is only for listening to. What is the best way - say 333/220 and use euclids algorithm?
Sample Rate conversion
Started by ●May 18, 2012
Reply by ●May 19, 20122012-05-19
On 5/18/12 8:46 PM, HardySpicer wrote:> My A/D samples at 33.33kHz and after processing I am using the sound > card to output the audio result. The sound card only accepts 44.1khz, > 22.05kHz etc. I am thinking of going 33.1 to 20.05. this doesn't have > to be spot on, just approx since it is only for listening to. What is > the best way - say > > 333/220 and use euclids algorithm? >what's euclids algorithm? -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●May 19, 20122012-05-19
On Fri, 18 May 2012 17:46:49 -0700, HardySpicer wrote:> My A/D samples at 33.33kHz and after processing I am using the sound > card to output the audio result. The sound card only accepts 44.1khz, > 22.05kHz etc. I am thinking of going 33.1 to 20.05. this doesn't have to > be spot on, just approx since it is only for listening to. What is the > best way - say > > 333/220 and use euclids algorithm?Secret Rabbit Code? Google it -- I think you need to pay if you want to use it commercially, but if it's just you, you just use it. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●May 19, 20122012-05-19
On 19/05/2012 01:46, HardySpicer wrote:> My A/D samples at 33.33kHz and after processing I am using the sound > card to output the audio result. The sound card only accepts 44.1khz, > 22.05kHz etc. I am thinking of going 33.1 to 20.05. this doesn't have > to be spot on, just approx since it is only for listening to. What is > the best way - say > > 333/220 and use euclids algorithm? >What OS is this on? Both Windows and OS X (at least) have built-in SRC, so if you can write your data into a standard WAVE format (assuming the srate is actually an integer, e.g. 33330 Hz), you can just play it. I could not even say for sure what hardware rate it would get converted to (some soundcards allow tou to specify a hardware srate), but if it "only for listening to" that will presumably not matter. the only caveat might be if you are using a playback engine that happens to talk direct to hardware (e.g. Kernel Streaming on Windows). Otherwise, those OSes by default include an SRC stage before reaching the card. Linux could be more of a problem, depending on what you use. Raw alsa will reject the sr, but some other tools such as media players will add src as necessary. There is also the sox 'play' command, which uses built-in src if required. Richard Dobson
Reply by ●May 19, 20122012-05-19
On May 20, 3:21�am, Richard Dobson <richarddob...@blueyonder.co.uk> wrote:> On 19/05/2012 01:46, HardySpicer wrote: > > > My A/D samples at 33.33kHz and after processing I am using the sound > > card to output the audio result. The sound card only accepts 44.1khz, > > 22.05kHz etc. I am thinking of going 33.1 to 20.05. this doesn't have > > to be spot on, just approx since it is only for listening to. What is > > the best way - say > > > 333/220 and use euclids algorithm? > > What OS is this on? Both Windows and OS X (at least) have built-in SRC, > so if you can write your data into a standard WAVE format (assuming the > srate is actually an integer, e.g. 33330 Hz), you can just play it. �I > could not even say for sure what hardware rate it would get converted to > (some soundcards allow tou to specify a hardware srate), but if it "only > for listening to" that will presumably not matter. the only caveat might > be if you are using a playback engine that happens to talk direct to > hardware (e.g. Kernel Streaming on Windows). Otherwise, those OSes by > default include an SRC stage before reaching the card. > > Linux could be more of a problem, depending on what you use. Raw alsa > will reject the sr, but some other tools such as media players will add > src as necessary. There is also the sox 'play' command, which uses > built-in src if required. > > Richard DobsonI'm using LabView and it only gives me the standard options - 44.1,20.05 etc Maybe there is a way to change it. hardy
Reply by ●May 19, 20122012-05-19
On May 19, 3:09�pm, robert bristow-johnson <r...@audioimagination.com> wrote:> On 5/18/12 8:46 PM, HardySpicer wrote: > > > My A/D samples at 33.33kHz and after processing I am using the sound > > card to output the audio result. The sound card only accepts 44.1khz, > > 22.05kHz etc. I am thinking of going 33.1 to 20.05. this doesn't have > > to be spot on, just approx since it is only for listening to. What is > > the best way - say > > > 333/220 and use euclids algorithm? > > what's euclids algorithm? > > -- > > r b-j � � � � � � � � �r...@audioimagination.com > > "Imagination is more important than knowledge."Greatest common divisor I think.
Reply by ●May 19, 20122012-05-19
On May 20, 3:21�am, Richard Dobson <richarddob...@blueyonder.co.uk> wrote:> On 19/05/2012 01:46, HardySpicer wrote: > > > My A/D samples at 33.33kHz and after processing I am using the sound > > card to output the audio result. The sound card only accepts 44.1khz, > > 22.05kHz etc. I am thinking of going 33.1 to 20.05. this doesn't have > > to be spot on, just approx since it is only for listening to. What is > > the best way - say > > > 333/220 and use euclids algorithm? > > What OS is this on? Both Windows and OS X (at least) have built-in SRC, > so if you can write your data into a standard WAVE format (assuming the > srate is actually an integer, e.g. 33330 Hz), you can just play it. �I > could not even say for sure what hardware rate it would get converted to > (some soundcards allow tou to specify a hardware srate), but if it "only > for listening to" that will presumably not matter. the only caveat might > be if you are using a playback engine that happens to talk direct to > hardware (e.g. Kernel Streaming on Windows). Otherwise, those OSes by > default include an SRC stage before reaching the card. > > Linux could be more of a problem, depending on what you use. Raw alsa > will reject the sr, but some other tools such as media players will add > src as necessary. There is also the sox 'play' command, which uses > built-in src if required. > > Richard Dobsonavtually I have had another look and you're right! the vi I was using was quite old and it is possible to output at any rate! much easier Thanks Hardy
Reply by ●May 19, 20122012-05-19
On May 18, 11:09�pm, robert bristow-johnson <r...@audioimagination.com> asked:> > 333/220 and use euclids algorithm? > > what's euclids algorithm?More accurately, it could be called Bezout's theorem. Given any two positive integers M and N, Euclid's algorithm for the greatest common divisor (gcd) can be used to compute gcd(M,N). Bezout's theorem (which I have known about for over forty years in the context of error-control coding but only recently learned is named after somebody called Bezout) says that there exist integers a and b such that aM + bN = gcd(M,N) Note that a and b usually have opposite signs. Furthermore, there exist integers c and d such that cM + dN = 0 The application to DSP is obvious, I hope. c and d tell you how to upsample a stream at one rate and downsample at a different rate to effect a rate conversion. These ideas are related to what is sometimes called the extended Euclidean algorithm. Starting from M and N, the Euclidean algorithm computes a _sequence_ of *remainders* ending in 0; the penultimate remainder is gcd(M,N). The *extended* Euclidean algorithm computes pairs of numbers (ai, bi) such that (ai)M + (bi)N = i-th remainder and the a,b,c,d used above are just the last two of these number pairs. Getting back to things of interest to comp.dsp, the extended Euclidean algorithm for *polynomials* is used for decoding BCH and Reed-Solomon codes, with one of the bi's being the error-locator polynomial and the i-th remainder being the error-evaluator polynomial. Hope this helps Dilip Sarwate
Reply by ●May 19, 20122012-05-19
dvsarwate <dvsarwate@yahoo.com> wrote:>These ideas are related to what is sometimes >called the extended Euclidean algorithm. >Starting from M and N, the Euclidean algorithm >computes a _sequence_ of *remainders* ending >in 0; the penultimate remainder is gcd(M,N). >The *extended* Euclidean algorithm computes >pairs of numbers (ai, bi) such that > >(ai)M + (bi)N = i-th remainderOkay now I am curious. This is not quite the formulation of the extended Euclidean algorithm I am familiar with. Suppose that initially you have M > N, R[-1] = M and R[0] = N. At the i-th stage of the Euclidean algorithm you have R[i-2] = Q[i] * R[i-1] + R[i] , i = 1, 2, 3... (which has the form R[i] = a * R[i-1] + b * R[i-2] so it's clear that what you state above is true; any R[i] can be expressed as the sum of multiples of the two preceding remainders; and by recursion this says it can be expressed as the sum of multiples any preceding pair of adjacent remainders; including the original pair, N and M.) For the extended algorithm, also compute: W[-1] = 0 W[1] = 1 W[i] = W[i-2] + Q[i] * W[i-1], i = 1, 2, 3... Then when R[n] = 0 at the end of the algorithm, W[n] = M/gcd(M,N) . (Congratulations, you have now done a long division.) In the algebraic decoding application with polynomials, W becomes the error locator so I think we must be stating the same "extended Euclidean" algorithm; but it seems you are computing more values than I would expect -- if you are explicitly calculating a[i] and b[i] at each step. Steve
Reply by ●May 19, 20122012-05-19
On May 19, 7:38�pm, spop...@speedymail.org (Steve Pope) wrote:> In the algebraic decoding application with polynomials, W becomes the > error locator so I think we must be stating the same "extended Euclidean" > algorithm; but it seems you are computing more values than I would > expect -- if you are explicitly calculating a[i] and b[i] at each step.In the algebraic decoding application, one of the a[i] and b[i] is of no interest whatsoever, and so only one sequence is computed. For what is is worth, the sequence left uncomputed follows the same recursion but with different initial conditions. Instead of W[-1] = 0 W[1] = 1 W[i] = W[i-2] + Q[i] * W[i-1], i = 1, 2, 3... it is X[-1] = 1 X[1] = 0 X[i] = X[i-2] + Q[i] * X[i-1], i = 1, 2, 3... For using the Bezout theorem (and the up/down sampling ratios application) both the sequences would be needed. The advantage of the iterative approach is that at any stage, only 6 (or 4) numbers need be stored; two remainders, two values of a[i] (and possibly two values of b[i]). The alternative, compute the remainders till you find the gcd and then work backwards till you express the gcd in terms of M and N requires more (and unpredictably variable) amount of storage. Dilip Sarwate
