Audio Asylum Thread Printer

Get a view of an entire thread on one page

Propeller Head Plaza

ASRC not necessarily bad.

65.19.76.104

In Reply to: RE: So... any idea why both of Wavelength and Ayre sound better,... posted by Todd Krieger on November 02, 2009 at 00:15:11

"That IMO would likely be the main "technical" reason why the Ayre and Wavelength would sound better."
Sorry Todd. While your old post may be applicable to some implementations of ASRC, it is not necessarily applicable to all implementations. Perhaps the ASRC in the Benchmark isn't good enough. I don't know, as I haven't heard the product or seen the necessary technical details (except that the output sample rate of 110 kHz seems inadequate on the face). IMO it is inappropriate to reject a design approach qualitatively, if there is a possible good implementation of that approach. However, one needs to carefully select any listening tests and/or measurements based on the technical approach in a product, if one wants to do a good job of evaluation.
I will now address each of your three points in your original post.
1. In particular, the whole point of using ASRC is to allow the use of a fixed output clock, something which can be built at much lower intrinsic jitter than a variable clock as needed for an analog PLL. It would be stupid to use this mechanism and not use a high quality oscillator, except for a cheap implementation where ASRC is used to eliminate the need for separate clocks for the 44.1 x n kHz and 48 x n kHz families of sampling rates.
2. In a proper implementation of ASRC it may be necessary to interpolate the output signal, since the input signal may appear between two output samples. If one does not do this, then there will be, as you suggest, jitter introduced. However, on can interpolate the output sample if one knows the time factor involved (see next paragraph).
Jitter in the input timing is eliminated in a proper ASRC by using a digital phase lock loop. This can be designed to have an extremely narrow lock bandwidth, a minute fraction of one second if desired. The limit is given solely by the long term stability (drift) of the oscillators and the acquisition delay (e.g. when the input source goes from one nominal sampling rate to a new one). There is nothing to preclude (in a sophisticated design) a wider initial bandwidth for rapid lock coupled with an increasingly narrow bandwidth once the input oscillator has been observed to be stable in frequency. A very small FIFO is used (perhaps only a latch) to accommodate the input jitter, and the output comes out at known points. (The ideal jitter free sample times computed by the digital PLL are referenced as fractional values measured according to the output clock which is the stable oscillator.) The resolution of these virtual times can be made arbitrarily large by representing them as binary fractions. The net result is that the uncertainty in timing can be reduced to a tiny fraction of an output clock sample. The known timing between samples is then input to the interpolation algorithm (next step).
3. The final stage of the process is to calculate an output sample. This occurs at integer clock ticks according to the output sampling rate. The input samples appear at constant periods not necessarily related to the output sample times. If one uses a zero order hold for the interpolation, one will get your jitter. But one can use as good interpolation as one wishes. For example the ASRC in the 24 bit SABRE chip uses 1st order interpolation at an output sample rate around 40 MHz. If this isn't good enough, one could use even higher order interpolation.
If one wants, one can built a system where input jitter has no effect on output jitter, measured down to the least significant bit (or even lower if desired) of the output samples. In other words, there would be no discernible jitter on the output of the sample rate conversion, as could be determined by looking at the digital samples. (There would still be jitter on the output analog signal due to the jitter of the output master clock, and if this weren't completely isolated electrically from the processing done by the ASRC function then there could still be coupling introduced this way, but this would be a criticism of the implementation of the ASRC, not its architecture.)
In short, there is no theoretical reason why an ASRC need corrupt the signal in any way shape or form. In practice, of course, that's another matter. Many ASRCs are used primarily as a cheap digital way of eliminating a more expensive crystal oscillator. The new Wavelength option is going to use the 32 bit SABRE chip, which has an ASRC as an (optional) feature. Gordon will have to comment on whether he will be using this feature or not. Presumably he will make this determination based on sound quality, as the cost of an extra oscillator isn't likely to be terribly important at his price point.

Tony Lauck

"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar

Edits: 11/02/09

Follow Ups:

RE: ASRC not necessarily bad. - Todd Krieger 18:04:19 11/02/09 (5)
"1. In particular, the whole point of using ASRC is to allow the use of a fixed output clock, something which can be built at much lower intrinsic jitter than a variable clock as needed for an analog PLL. It would be stupid to use this mechanism and not use a high quality oscillator, except for a cheap implementation where ASRC is used to eliminate the need for separate clocks for the 44.1 x n kHz and 48 x n kHz families of sampling rates."
But the whole problem is **how** this jitter is "eliminated"....... What happens is the time shifted data is re-sampled by the precise output clock, but because the data being sampled was time-shifted (due to the input jitter), the sampled data isn't at the correct amplitude. (The time shift means the output grabs the amplitude from the signal, interpolated at an extremely high rate, slightly before or after where it should have taken place.) This is where the whole problem is.
"2. In a proper implementation of ASRC it may be necessary to interpolate the output signal,"
It is not only necessary, but it wouldn't otherwise function in this particular implementation...... (I think you meant to say "input signal.")
"since the input signal may appear between two output samples. If one does not do this, then there will be, as you suggest, jitter introduced."
That's not where jitter is introduced, at face value. What happens is if the input signal is time-shifted from jitter, which the intermediate interpolated signal is correlated to, what's sent to the output will not be of correct amplitude, and these amplitude errors, which is a function of the input jitter, introduce noise.
"However, on can interpolate the output sample if one knows the time factor involved (see next paragraph)."
I'm not sure what you mean by "time factor"...........
"Jitter in the input timing is eliminated in a proper ASRC by using a digital phase lock loop."
The PLL supposedly reduces jitter, whether it's ASRC or not. The PLL is not unique to ASRC playback. Many older synchronous conversion DACs use PLL for jitter reduction.
"This can be designed to have an extremely narrow lock bandwidth, a minute fraction of one second if desired. The limit is given solely by the long term stability (drift) of the oscillators and the acquisition delay (e.g. when the input source goes from one nominal sampling rate to a new one). There is nothing to preclude (in a sophisticated design) a wider initial bandwidth for rapid lock coupled with an increasingly narrow bandwidth once the input oscillator has been observed to be stable in frequency. A very small FIFO is used (perhaps only a latch) to accommodate the input jitter, and the output comes out at known points. (The ideal jitter free sample times computed by the digital PLL are referenced as fractional values measured according to the output clock which is the stable oscillator.) The resolution of these virtual times can be made arbitrarily large by representing them as binary fractions. The net result is that the uncertainty in timing can be reduced to a tiny fraction of an output clock sample. The known timing between samples is then input to the interpolation algorithm (next step)."
Useful for those who want an idea how a PLL works.............
"3. The final stage of the process is to calculate an output sample. This occurs at integer clock ticks according to the output sampling rate. The input samples appear at constant periods not necessarily related to the output sample times. If one uses a zero order hold for the interpolation, one will get your jitter. But one can use as good interpolation as one wishes. For example the ASRC in the 24 bit SABRE chip uses 1st order interpolation at an output sample rate around 40 MHz. If this isn't good enough, one could use even higher order interpolation."
What gets lost here is the intermediate interpolated signal is still correlated to the *input*....... (The PLL might reduce it, but it's still there.) Once again, if there is a shift from jitter, what's actually sampled to the output, which is from that interpolated signal, will contain an amplitude error, due to the sample being grabbed slightly before or after it should have been.

Edits: 11/02/09
- RE: ASRC not necessarily bad. - Tony Lauck 19:49:14 11/02/09 (4)
  "What happens is if the input signal is time-shifted from jitter, which the intermediate interpolated signal is correlated to, what's sent to the output will not be of correct amplitude, and these amplitude errors, which is a function of the input jitter, introduce noise."
  
  This noise comes from three sources, all of which can be addressed.
  
  1. Error in estimating the time at which the input signal should have arrived if it were jitter free. (Reduce this error by using a better digital PLL, one that averages over a longer time period and which using more bits of virtual time resolution.)
  
  2. Error in performing the interpolation between output clock points due to inaccurate algorithm. (Reduce this error by using a higher order interpolator or a higher output sample rate or a combination of the two.)
  
  3. Error in calculating the interpolated values. (Use a longer word length in the interpolation calculations.)
  
  Tony Lauck
  
  "Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
  - RE: ASRC not necessarily bad. - Todd Krieger 21:43:50 11/02/09 (3)
    "1. Error in estimating the time at which the input signal should have arrived if it were jitter free."
    
    Since PLLs have been common prior to ASRC (my Prism DA-2 DAC uses it), if it completely eliminated jitter (it doesn't in the real world), then using ASRC to eliminate something that was *already* eliminated would be pointless. (Unless variable input or output rates were to be utilized, which is the one thing ASRC has over synchronous conversion. A true jitter-free input signal would eliminate the noise issue. But no ideal exists in the real world. And still, the ASRC isn't what would even be actually eliminating the jitter. It would only benefit from the PLL doing so.)
    
    "2. Error in performing the interpolation between output clock points due to inaccurate algorithm. (Reduce this error by using a higher order interpolator or a higher output sample rate or a combination of the two.)"
    
    I'm not sure what you mean by "between output clock points"...... The interpolation is actually performed *prior* to the output clock sending samples to the output. The samples sent to the output are *already* interpolated. (This is why if there's jitter on that interpolated signal, which is correlated to the input signal/PLL, the errors at the output would be that of amplitude/noise.)
    
    "3. Error in calculating the interpolated values. (Use a longer word length in the interpolation calculations.)"
    
    With the sheer speed of the calculations in such high oversample rates utilized in ASRC, this *might* be an issue. But to be honest, I think the jitter in the signal would likely result in larger errors, unless some calculations were corrupted outright. (Such errors would render a DAC unusable.) The output is good enough (in this context) to quench such doubt.
    
    I think the ultra-high oversample rate performed in ASRC in itself is a technological achievement. (The processing power has got to be downright immense.) But since there is no readily explicit information on how these values are actually generated, I'd raise the question in regard to short-cuts possibly being done in order to achieve such high oversample rates.
    
    At the end of the day, I think asynchronous conversion should have never seen the light of day in consumer CD playback. And also consumer CD recordings. I think CDs cut from a high-rez 24/192 master is a similar compromise.
    - RE: ASRC not necessarily bad. - Tony Lauck 06:13:51 11/03/09 (2)
      I'm sorry that my explanation was difficult to understand. It's a difficult subject, and no doubt the inherent difficulty has resulted in many designs that don't quite work correctly. For a description of some of the compromises applied in practical designs (which have been reported by audiophiles to be good sounding) look at the white paper for the ESS SABRE chip and the patent filing on ASRC technology by the authors of the paper.
      
      There is no point in arguing the case against using analog PLLs to derive sample clocks. This has been discussed numerous times in numerous threads. If you have one that has low enough jitter that it doesn't bother you, then I'd just enjoy it.
      
      Tony Lauck
      
      "Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
      - RE: ASRC not necessarily bad. - Todd Krieger 10:44:18 11/03/09 (1)
        
        In Reply to: RE: ASRC not necessarily bad. posted by Tony Lauck on November 03, 2009 at 06:13:51
        
        I listened to the SABRE chip at the L.A. Can Jam several months ago. It was actually one of the better performers there. Although it was with music that I was unfamiliar with, so I couldn't really compare it to anything.
        
        RE: ASRC not necessarily bad. - Tony Lauck 12:40:06 11/03/09 (0)
        
        In Reply to: RE: ASRC not necessarily bad. posted by Todd Krieger on November 03, 2009 at 10:44:18
        
        As I understand it, it is possible to bypass the ASRC on the SABRE chip if one runs the chip with a master clock that is an appropriate multiple of the sample rate. That would be up to the DAC, i.e. if it didn't use the built-in ASRC it would probably need to have two different master clocks to accommodate the 44.1 and 48 kHz families of sampling rates.
        
        Do you recall the DAC that was running at the demo?
        
        Tony Lauck
        
        "Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar

Post a Followup:

FAQ

Post a Message!

Forgot Password?

Moniker (Username):
Password (Optional):
	Remember my Moniker & Password (What's this?) Eat Me
E-Mail (Optional):
Subject:

Message:	(Posts are subject to Content Rules)

Optional Link URL:
Optional Link Title:
Optional Image URL:
Upload Image:
E-mail Replies:	Automagically notify you when someone responds.

To view your new posting or follow-up, click on the RELOAD or REFRESH button on your browser.