Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Schallfeldnebel]

Hi Dan,

Can your SRC in sychronus mode be clocked from a second 3000 in sychronus mode?

Erik Sikkema

[C-J]

Daniel Weiss wrote on Wed, 14 September 2005 22:57

C-J wrote on Wed, 14 September 2005 21:11 Could you (easily) explain what a Polyphase Filter means? In a nutshell: As an example of a polyphase filter used in an SRC - it is a large FIR filter. A symmetrical FIR filter has a constant delay (linear phase response). The polyphase filter now takes only a subset of all coefficients of that long FIR for any given output sample, i.e. output sample # 1 is calculated using subset # 1, output sample # 2 uses subset # 2 and so forth. Now, the subset #1 takes every Nth coefficient of the FIR starting with coefficient # 1. The subset # 2 takes every Nth coefficient starting with coefficient # 2. So the resulting FIR for any given output sample has still the same amplitude response as the "complete" FIR (the full set of coefficients), but the delay through the FIR varies for each subset. Hence the term polyphase. So this polyphase filter lets you calculate values between any two sample points. Example: For a 44.1 to 88.2 conversion you need to calculate a new value exactly midway (on the time axis) between two sample values of the original 44.1, so in that case you would have two subsets in the polyphase filter, one with delay 0 (so to speak) and one with delay half a sampling period of 44.1. Other examples: For a 44.1 to 3 times 44.1 conversion you need three subsets, each 1/3rd of a sampling period apart in their delays. For a 44.1 to 48 conversion you need 160 subsets, because you first go up to 160 times 44.1kHz (=7.056MHz), i.e. this gives you a fine grid of samples, 160 samples per 44.1k sampling period. Out of that fine grid you take every 147th sample and this is your 48kHz output. I hope that helps a little - google gives more than 27000 hits for "polyphase filter", so the concept is not that exotic... Daniel

Thanks Daniel,

Well, I have now read your answer 65535 times, and studied Polyphase filters for a few weeks, not ALL 27000 hits, though. But, somehow, I cannot see the mathematical "beauty" of the polyphase function? I got the impression that ONE purpose, is to (re)use excisting hardware, by running "parallell" processes at higher calculating rates?

From reading Dan's and Nika's writings. I think I understand the basics of FIR filters. We take a chosen amount of coefficients (the sum of which =1, in an LPF), which we then multiply one by one, with the same amount of backward input taps, stored into shift registers. Finally, we add the products of each multiplication. If we want a Phase Linear FIR, we rotate the coefficients, (like CBABC), instead of going back and forth along the taps.

If  we do a 4x upsample, and call the original samples "a", and the new, interpolated samples "b,c,d,", we get a string of "abcdabcd...". If we then use an FIR LPF with 16 coefficients, named "A-P", the 1st subset uses "AEIM", the 2nd "BFJN", and so on... Now,,, some stupid questions. Is the coefficent's sum of each coefficient subset =1, or =1/4?

What taps do we use? The old "a" taps only, or, all "abcd" taps. If so, won't we have to multiply all original "a" tap values by 4, to compensate for the zero valued "bcd" taps? (p159/160 in Nika's book.)

Whichever we use, I can see two choices when we start to multiply the taps by the rotated four coefficient subsets. Either we use the very same four taps, and multiply them in turns by the rotated subsets. Or, we use a total of 16 backward taps:
"n, n(-4), n(-8), n(-12)" for the 1st subset, "n(-1), n(-5), n(-9), n(-13)" for the 2nd subset, and so on... (Here the "n" could point to either "a" taps only, or to "abcd" taps.)

However this is done, I have troubles in understanding why, the use of four rotated subset calculations would be any better, than to use a single set of four coefficients? Anyway, compared to using the 'long' 16 tap filter for each individual calculation, wouldn't all three options yield different output sample values?

Hopefully somebody, now post AES, could find the time to steer me into the right direction.

Lost in polyspace, C.J., Finland

[Jon Hodgson]

Hi C-J

You've almost got it, except you've got the first bit wrong.

When you first upsample, before the reconstruction filter, a stream of samples
AAAAAAAAAAAAAAAAAA

You don't get

ABCDABCDABCD which you then feed into the filter,

what you get is A000A000A000A000

You then feed it through a convolution filter to get

abcdabcdabcdabcd

But if you think about it, a FIR filter is

sample0 * tap0 + sample1 * tap1 = sample2 * tap2... and so on

So at any time, 3 out of four of those calculations will be redundant, so in your case of a 16 tap FIR, only four taps will be required for each output sample, a different set of taps for each output sample in a set of four.

[Daniel Weiss]

C-J wrote on Sat, 15 October 2005 21:57

Daniel Weiss wrote on Wed, 14 September 2005 22:57 C-J wrote on Wed, 14 September 2005 21:11 Could you (easily) explain what a Polyphase Filter means? In a nutshell: As an example of a polyphase filter used in an SRC - it is a large FIR filter. A symmetrical FIR filter has a constant delay (linear phase response). The polyphase filter now takes only a subset of all coefficients of that long FIR for any given output sample, i.e. output sample # 1 is calculated using subset # 1, output sample # 2 uses subset # 2 and so forth. Now, the subset #1 takes every Nth coefficient of the FIR starting with coefficient # 1. The subset # 2 takes every Nth coefficient starting with coefficient # 2. So the resulting FIR for any given output sample has still the same amplitude response as the "complete" FIR (the full set of coefficients), but the delay through the FIR varies for each subset. Hence the term polyphase. So this polyphase filter lets you calculate values between any two sample points. Example: For a 44.1 to 88.2 conversion you need to calculate a new value exactly midway (on the time axis) between two sample values of the original 44.1, so in that case you would have two subsets in the polyphase filter, one with delay 0 (so to speak) and one with delay half a sampling period of 44.1. Other examples: For a 44.1 to 3 times 44.1 conversion you need three subsets, each 1/3rd of a sampling period apart in their delays. For a 44.1 to 48 conversion you need 160 subsets, because you first go up to 160 times 44.1kHz (=7.056MHz), i.e. this gives you a fine grid of samples, 160 samples per 44.1k sampling period. Out of that fine grid you take every 147th sample and this is your 48kHz output. I hope that helps a little - google gives more than 27000 hits for "polyphase filter", so the concept is not that exotic... Daniel Thanks Daniel, Well, I have now read your answer 65535 times, and studied Polyphase filters for a few weeks, not ALL 27000 hits, though. But, somehow, I cannot see the mathematical "beauty" of the polyphase function? I got the impression that ONE purpose, is to (re)use excisting hardware, by running "parallell" processes at higher calculating rates? From reading Dan's and Nika's writings. I think I understand the basics of FIR filters. We take a chosen amount of coefficients (the sum of which =1, in an LPF), which we then multiply one by one, with the same amount of backward input taps, stored into shift registers. Finally, we add the products of each multiplication. If we want a Phase Linear FIR, we rotate the coefficients, (like CBABC), instead of going back and forth along the taps. If  we do a 4x upsample, and call the original samples "a", and the new, interpolated samples "b,c,d,", we get a string of "abcdabcd...". If we then use an FIR LPF with 16 coefficients, named "A-P", the 1st subset uses "AEIM", the 2nd "BFJN", and so on... Now,,, some stupid questions. Is the coefficent's sum of each coefficient subset =1, or =1/4? What taps do we use? The old "a" taps only, or, all "abcd" taps. If so, won't we have to multiply all original "a" tap values by 4, to compensate for the zero valued "bcd" taps? (p159/160 in Nika's book.) Whichever we use, I can see two choices when we start to multiply the taps by the rotated four coefficient subsets. Either we use the very same four taps, and multiply them in turns by the rotated subsets. Or, we use a total of 16 backward taps: "n, n(-4), n(-8), n(-12)" for the 1st subset, "n(-1), n(-5), n(-9), n(-13)" for the 2nd subset, and so on... (Here the "n" could point to either "a" taps only, or to "abcd" taps.) However this is done, I have troubles in understanding why, the use of four rotated subset calculations would be any better, than to use a single set of four coefficients? Anyway, compared to using the 'long' 16 tap filter for each individual calculation, wouldn't all three options yield different output sample values? Hopefully somebody, now post AES, could find the time to steer me into the right direction. Lost in polyspace, C.J., Finland

See answer by Jon Hodgson which sheds some light. I.e. I should have mentioned that first the upsampling is done by so called zero filling, e.g. in the case of 4 times upsampling there are three zero valued samples filled in between each sample of the original signal. As described by Jon. When you feed that upsampled signal to the large FIR then the "subsets of coefficents" will be used automatically (four subsets for the very same four taps). Yes, the sum of the coefficients in a subset is 1/N for all subsets, N being the upsampling factor. So the amplitude response is constant (which is good) and the phase response is variing for that fractional delay we want to achieve (which is also good).

Daniel

[Bogic Petrovic]

Hi all,

danlavry wrote on Sat, 17 September 2005 18:14

..... Say you have an independent stand alone 44.1KHz source, and you force a synchronous conversion to 96KHz. Say the house sync is at (96KHz + 10ppm), and the source is (44.1KHz -10ppm) (meaning the converted 96KHz is 96KHz -10ppm). Now you have a mismatch between a 96KHz house sync (or DAW clock) and the newly converted 96KHz audio. You can not just send the audio in - it calls for a new SRC task, from (96KHz -10ppm) to (96KHz -10ppm). This time, your SRC is Asynchronous. At this point, you may have considered a one step Asynchronous 44.1KHz to 96KHz.... ....

I agree with you Dan, and in Sample Rate Conversion between two independent clocks there is not such thing that we can call "synchronous", even if ratio is "1:1". Things can be "synchronous" only if we tolerate loss of samples (fifo is full, slave clock is a bit slower than master) or pauses with silence (fifo is empty, slave clock is a bit faster than master).

If we have great probability to see this situation in real world, then we cannot discuss about Synchronous Sample Rate Conversion, because we cannot have independent clocks with precise rational ratios. In this case things are real, not rational... and that means that we have analog behavior, not digital... we must remember that in overall story about digital audio we still have one thing analog - TIME!

Best regards,

-boggy

[Graham Jordan]

You certainly can have situations where a synchronous SRC is totally acceptable and does not run into any 'dropping of samples'. And these days I think there are more situations where you can use this - namely DAWs. Yes when transferring digital audio from one clocked system to another independently clocked system (even if they're both nominally the same rate, like 44.1kHz) you need asynchronous SRC unless you can tolerate dropped and/or repeated samples. (e.g. standard CD digital output to any digital device that does extract and synchronise the whole system to that CD clock)

However, if the two sample rates are dependant, then you can do synchronous.

For example: SRC on an audio file - synchronous (as no actual clocks are used, simply the implied clock in the original, and the known exact ratio to the target implied clock).

Another example: a system is running in real time at a certain clock/sample rate, and uses SRC to send data out at a different rate, where the output rate is exactly locked to the system rate - synchronous.

Also, internal up/down-sampling if needed for processing.

Also mastering etc.

So asynchronous is for independent clocks yes - that's it's definition.

Synchronous is for dependant clocks - which is a situation that does occur, not some theoretical situation.

[twilightsong]

I skimmed through the thread

Back to the question of SRC: of late I've been "worrying" about how I downsample to 16/44.1. I've been shown graphical representations of how various products effect the result when doing this. Some of his was admitedly related to salesmanship of a product called R8Brain Pro (Voxengo, $119) which supposedly yields an audibly "cleaner" result

I'm always wary of peeps who say their product is "the best" even and especially when it's NOT a paid endorsement, but I've heard quite a few that this app is so wonderful... I wish I'd never heard of it because I lay in bed at night wondering if I "need" to buy it

[Ronny]

twilightsong wrote on Sat, 12 November 2005 16:19

I skimmed through the thread Back to the question of SRC: of late I've been "worrying" about how I downsample to 16/44.1. I've been shown graphical representations of how various products effect the result when doing this. Some of his was admitedly related to salesmanship of a product called R8Brain Pro (Voxengo, $119) which supposedly yields an audibly "cleaner" result I'm always wary of peeps who say their product is "the best" even and especially when it's NOT a paid endorsement, but I've heard quite a few that this app is so wonderful... I wish I'd never heard of it because I lay in bed at night wondering if I "need" to buy it

The R8Brain won't beat out the Weiss, but it's been holding it's own with and looking better than some of the more common SRC's. The freebie R8Brain has exhibited better results on some tests than the Pro version. You may want to save yourself some bucks and go with the freebie. Also keep in mind with the SRC comparison graphs where the actual noise floor is located.

[bobkatz]

Graham Jordan wrote on Thu, 10 November 2005 13:16

So asynchronous is for independent clocks yes - that's it's definition. Synchronous is for dependant clocks - which is a situation that does occur, not some theoretical situation.

Although you can put a dependent clock on an asynchronous converter's sync input. Why would you do that? Well, it can sound better. I learned from Bruno Petsys and verified by listening and measurement that the TI ASRC chip completely rejects jitter if its secondary is an integer multiple or submultiple and framed to the incoming clock!

The rate converter firmware in the chip's estimate of outgoing sample rate then tracks the incoming rate completely.

BK

[Bogic Petrovic]

bobkatz wrote on Sun, 13 November 2005 20:04

Graham Jordan wrote on Thu, 10 November 2005 13:16 So asynchronous is for independent clocks yes - that's it's definition. Synchronous is for dependant clocks - which is a situation that does occur, not some theoretical situation. Although you can put a dependent clock on an asynchronous converter's sync input. Why would you do that? Well, it can sound better. I learned from Bruno Petsys and verified by listening and measurement that the TI ASRC chip completely rejects jitter if its secondary is an integer multiple or submultiple and framed to the incoming clock! .... BK

Hi Bob,

If I understand ASRC mechanism, ASRC can reject overall jitter if we slave its input clock to incoming (jittered) clock, and their output clock to (new, internal, quartz oscillator generated and independent) "jitter-free" clock. ASRC has their own oscillator, but in slave mode we can use more stable clock oscillator than this included in chip. Our MASTER clock can be ovenized quartz crystal oscillator with good power supply. This realisation isn't cheap but we may have lowest jitter as possible today. Main role in this play ASRC.

IFAIK, there isn't a request for integer ratio within input and output clocks.

Your incoming clock can be 47.998kHz and outgoing 44.105kHz, ASRC can do this. Even, incoming clock can be 47.998 and outgoing can be 48.006, ASRC "adjust" samples to outgoing clock, and we have new stream without low frequency jitter down to about 3-4Hz. Also, ordinary PLLs cannot reject low frequency jitter well, because their VCAs has bigger noise at this frequencies. Simply, PLLs generate their own, and new jitter at low frequencies.

Jitter can be fighted only relative to jitter-free clock. ASRC don't synchronise clocks, but make new samples regarding to new jitter free clock, and then we have signal without input clock jitter, only with output clock jitter. And this clock we can keep to be virtually "jitter-free".

In telecommunications, low frequency jitter and lowest frequency wander, is attenuated with ADC, DAC and with software in microprocessor... this means "software" PLL. ASRC is one great  and very low-cost idea when we have problems with jitter at low frequencies. Ordinary PLLs cannot attenuate low frequency jitter well.

There is also problem with high frequency ratios in PLLs used in digital audio, good rule of thumb is that input and output frequencies may be in 1:2 ratio, if we need good jitter attenuation... but when we have 1:64, or 1:128 ratios in digital audio... this is a hard job for ordinary PLLs.



best regards,

-boggy

[bobkatz]

boggy wrote on Sun, 13 November 2005 15:27

bobkatz wrote on Sun, 13 November 2005 20:04 Graham Jordan wrote on Thu, 10 November 2005 13:16 So asynchronous is for independent clocks yes - that's it's definition. Synchronous is for dependant clocks - which is a situation that does occur, not some theoretical situation. Although you can put a dependent clock on an asynchronous converter's sync input. Why would you do that? Well, it can sound better. I learned from Bruno Petsys and verified by listening and measurement that the TI ASRC chip completely rejects jitter if its secondary is an integer multiple or submultiple and framed to the incoming clock! .... BK Hi Bob, If I understand ASRC mechanism, ASRC can reject overall jitter if we slave its input clock to incoming (jittered) clock, and their output clock to (new, internal, quartz oscillator generated and independent) "jitter-free" clock.

Unfortunately it does not work that way. When the output clock is a crystal clock, the output clock itself may be relatively jitter free, but the output data stream still may contain artifacts (distortion) of the jitter from the incoming clock, minus the jitter rejection qualities of the ASRC's digital phase locked loop. What the ASRC does is to change its sampling filter as a continuously running estimate of the incoming sample rate and it is the continuously-running estimate of the sample rate ratio that causes potential distortion in the outgoing data.

However, as I pointed out, the TI chip has a unique situation in which it COMPLETELY (100%) rejects the jitter from the incoming clock if the outgoing clock is slaved and framed to the incoming clock (e.g. EXACTLY 1/2 or 2X the incoming clock and derived from the incoming clock's edges). It doesn't even matter if the incoming clock is very jittery and the outgoing clock is jittery in this unique case, the ASRC's sample rate estimation filter is slaved to the relationship between the clocks and therefore jitter-insensitive, if you get my drift.

BK

[Bogic Petrovic]

[quote title=bobkatz wrote on Sun, 13 November 2005 22:02]

boggy wrote on Sun, 13 November 2005 15:27

bobkatz wrote on Sun, 13 November 2005 20:04 Graham Jordan wrote on Thu, 10 November 2005 13:16 I learned from Bruno Petsys and verified by listening and measurement that the TI ASRC chip completely rejects jitter if its secondary is an integer multiple or submultiple and framed to the incoming clock! .... BK Hi Bob, If I understand ASRC mechanism, ASRC can reject overall jitter if we slave its input clock to incoming (jittered) clock, and their output clock to (new, internal, quartz oscillator generated and independent) "jitter-free" clock. Unfortunately it does not work that way. When the output clock is a crystal clock, the output clock itself may be relatively jitter free, but the output data stream still may contain artifacts (distortion) of the jitter from the incoming clock, minus the jitter rejection qualities of the ASRC's digital phase locked loop. What the ASRC does is to change its sampling filter as a continuously running estimate of the incoming sample rate and it is the continuously-running estimate of the sample rate ratio that causes potential distortion in the outgoing data.

Can you point me out to any documents about this phenomenon.
I'm interested about issue when we have independent or dependent clocks but with near 1:1 ratio. REP forum probably isn't a place for discuss that deep theory.  

Quote:

However, as I pointed out, the TI chip has a unique situation in which it COMPLETELY (100%)

100%? Sounds pretty good for me

Quote:

rejects the jitter from the incoming clock if the outgoing clock is slaved and framed to the incoming clock (e.g. EXACTLY 1/2 or 2X the incoming clock and derived from the incoming clock's edges). It doesn't even matter if the incoming clock is very jittery and the outgoing clock is jittery in this unique case, the ASRC's sample rate estimation filter is slaved to the relationship between the clocks and therefore jitter-insensitive, if you get my drift. BK

You provide a great information for me.
Unfortunately, as I expect, ASRC chips works only near to same principle... this is a yet another compatibility problem.
Umm, I'm already tired a bit about digital audio "compatibility" issues.  

Many thanks.

Best regards,

-boggy

[bobkatz]

boggy wrote on Sun, 13 November 2005 17:52

Can you point me out to any documents about this phenomenon. I'm interested about issue when we have independent or dependent clocks but with near 1:1 ratio. REP forum probably isn't a place for discuss that deep theory.

Bob Adams' original paper on the theory and practice of the Analog Devices 1890 chip would be the place to look. It was a very thorough review of the technology behind that chip. I have no idea where to find that paper today, it was written long before even PDFs were popular.

I may have a paper copy somewhere in my file boxes.

BK

Quote:

You provide a great information for me. Unfortunately, as I expect, ASRC chips works only near to same principle... this is a yet another compatibility problem. Umm, I'm already tired a bit about digital audio "compatibility" issues.

I think this situation is unique to the TI chip. I've never seen it documented on any other chip. The other competitors are the Analog Devices 1896, and the Crystal 8420 (I think that's the number). Nudge, nudge, wink, wink... the Crystal chip is the one to have!

BK

[Bogic Petrovic]

bobkatz wrote on Sat, 19 November 2005 01:03

....competitors are the Analog Devices 1896, and the Crystal 8420 (I think that's the number). Nudge, nudge, wink, wink... the Crystal chip is the one to have! BK

Nevermind, i think that Cirrus Logic (ok, Crystal ) has new one... CS8421.
One interesting ability of this chip is 32bit non-dithered output stream. Input stream can also be 32bit.


Best regards,

-boggy

[Deep White]

Dear All,

I'm not sure if this question belongs to a minor league, but what do you think about the SRC in Samplitude?