Daniel Weiss wrote on Fri, 16 September 2005 04:59 |
danlavry wrote on Thu, 15 September 2005 22:15 |
But when we work in a real world audio studio, with one clock is set to 44.1KHz, and the other to 96KHz, we are talking about 2 physically different crystal clocks. Now say the 44.1KHz drifts up by say 7 ppm and the 96KHz drifts down by say 4ppm. The total relative drift is 11ppm. The frequency ratio changes with temperature, with component aging…
|
Ok, but Bob (I figure) and I haven't talked about such a scenario, we talked about one where the two rates (e.g. 44.1 and 96) are generated from the same "superclock" source and hence are synchronous. As in your example with 44.1kHz and 88.2kHz where the least common multiple is 88.2kHz, the least common multiple for 44.1kHz and 96kHz is 14.112MHz.
You wrote:
Quote: |
As a rule, you are better off to stay within a ratio of 2:1 (such as 44.1 to 88.2) than to go for a non integer ratio such as 2.176870748.... (such as 44.1 to 96KHz). The integer ratio requires much simpler sample rate conversion - an asynchronous conversion. The non integer ratio takes much more computations therefore it has greater potential for errors.
|
You assume here that the 44.1 and 96 rates are asynchronous. That can be in a general case, but isn't necessarily so.
Daniel www.weiss.ch
|
One could, for example have a high frequency source, a 14.112MHz clock can be divided by 320 to yield 44.1KHz and the same 14.112MHz clock can be divided by 147 to yield 96KHz. That would indeed produce synchronous clock trains, and if one forces their SRC to receive those clocks, it is possible to have synchronous operation.
But A TYPICAL APPLICATION of SRC is NOT based on such a case.
You and Bob assumed one case, and I assumed the other but
THE VAST MAJORITY of studios I know have an independent clock such as a house sync, for the output clock, while the data comes in to the SRC is based on another physical clock rate. Such applications are NOT synchronous, and they call for an asynchronous SRC conversion.
I would certainly accept an argument that states clearly that one can force the 44.1 to 96 to be synchronus, by having a common high frequency clock and dividers. But as you agreed "the general case" of such conversion calls for an asynchronus.
It is correct to say that one can use synchronous techniques to accomplish asynchronous results, by imposing a quantizing time grid on the conversion. This is similar voltage in digital audio, quantized to say 16 bits (65384 grid lines) and so on...
When quantizing the voltage, we want the grid to be as fine as the noise floor. When quantizing the time, we want the grid to be as fine as jitter (time domain noise).
So how many "grid lines" of say 10psec fit between say 44.1KHz samples? With time between samples at about 22.7usec, you need a grid of about 2.27 million! Is it a big deal? Yes it is. So lets go for a time grid of 100psec (pretty crude from sampling time standpoint) and we still need 227000 grid lines. Why is it a big deal? Because in an ideal case, each grid line represents a complete and unique set of FIR set of coefficients. The “quantized” SRC, where we use a synchronous SRC to approximate an asynchronous SRC by “bouncing” between fine time grid lines, just takes too much coefficient storage.
Well, there are solutions, and the common one is to have a rather coarse grid (coefficient table), as large a table as we can reasonably fit into the silicon, and the fine grid will be computed by interpolation. Now this is an approximation! Some implementations work better then others, and in fact the various solutions have serious tradeoffs.
In other words, SRC is more than a magic box with data in/data out. The question was “what works best” and for what case.
1. In a studio environment, most 44.1 to 96 (or 96 to 44.1) are asynchronous, the clocks are independent and knowing where one clock transition is does not tell you where the other clock transitions are.
2. If one can stay within the bounds of 2:1, one can get better results (greatly simplified calculations).
3. Alternativly, one can get the better results if they operate the SRC from a single clock source with dividers. That calls for aditional hardware generating (and distributing) all the clocks in a studio from one high frequency source divisable to all the desired rates.
3. When operating with asynchronus clocks, my understanding of Bob and Daniel’s remarks is that “one can use a synchronous process” to do a job in an asynchronous case. That is how polyphase SRC works. But is it a synchronous SRC? Or is it an asynchronous SRC? The process is a synchronous one (bouncing between time positions on a synchronous grid). The application is asynchronous one, moving data from one clock to another clock that is not in sync.
I called it asynchronous conversion, because it reflects the user’s point of view.
Bob, do you still disagree with what I say?
Regards
Dan Lavry
www.lavryengineering.com