Go Back   Home > Forums > >
Home Forums Rules Articles diyAudio Store Blogs Gallery Wiki Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

Digital Source Digital Players and Recorders: CD , SACD , Tape, Memory Card, etc.

Asynchronous Sample Rate Conversion
Asynchronous Sample Rate Conversion
Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Thread Tools Search this Thread
Old 25th February 2004, 10:53 PM   #21
dcole is offline dcole
diyAudio Member
dcole's Avatar
Join Date: Dec 2002
Location: Seattle
Default So Far So Good...

Thanks Werewolf! So far I'm with you. Your definitions definitely helped. I have a some questions, but they are mainly implementation questions or relating to stuff you haven't talked about yet, so I'll be patient.

  Reply With Quote
Old 25th February 2004, 11:02 PM   #22
werewolf is offline werewolf  United States
diyAudio Member
Join Date: Feb 2004
Location: Austin, TX
dddac, thanks for the posts ...

My experience with Asynchronous Sample Rate Converters includes architecture, design, test & measurement of silicon implementations, as well as limited personal use in audio equipment. It's my intention with this thread to describe the technical details of how they work, and provide a performance comparison to PLL-based clock recovery schemes. And I welcome any feedback about how they sound

I have no direct experience with the dddac1543. But your measurements of the various audio spectra look quite puzzling. The effects of Asynchronous Rate Conversion, implemented in devices like the CS8420 & the AD1896, are particularly easy to measure, and should not vary THAT dramatically from DAC to DAC ... for the simple reason that any DACs in question will be clocked by a local, ultra-clean crystal oscillator in the ASRC environment, so any varying jitter-sensitivities between DACs will be completely eliminated. Which, of course, leaves only the audio band data. Why would two DACs, each clocked by an ultra-clean clock, have such dramtically different responses to the same audio band data, and hence the same audio band input spectrum? I suggest the problem is not in the ASRC.

But please allow me to ask some questions for clarification :

1. Just to make sure, you are referring to Asynchronous Sample Rate Conversion, and not simply Asynchronous Re-Sampling, correct? I know you mentioned the CS8420, which does indeed perform Asynch Rate conversion ... that is, re-calculating the correct audio output samples that correspond to the new time points.

2. Were the observations you made ... namely, different DACs responding differently to the rate-converted data ... driven by the same data, at the same time? I ask because I know the CS8420 has had it's share of bugs & glitches over the years.

Again, the time base for the DACs is ultra-clean in an ASRC environment, which leaves ONLY the baseband data itself, and it's corresponding audio spectrum, to "misbehave". If one DAC processes this baseband data accurately, and another doesn't ... I would look to the DAC rather than the ASRC.

And a digital filter such as the DF1704 should have no effect (or at least, very minimal) on the baseband audio spectrum ... again, the clocks for the filters & DACs are ultra-clean, so clocking is removed as a variable.

If you guys find this explanation unconvincing, I'm wide open to any theories that would explain the TERRIBLE performance displayed in dddac's spectra, that would implicate the ASRC ... ???
  Reply With Quote
Old 26th February 2004, 01:42 AM   #23
werewolf is offline werewolf  United States
diyAudio Member
Join Date: Feb 2004
Location: Austin, TX
We may be in for a long thread .... But let's move forward !

So, we have a situation where we need to digitally CALCULATE output data samples at new points in time, different than the input data time points. And the time points are NOT synchronized ... so there is no finite integer interpolation that we can perform on the input data that will align perfectly with the output time points we need.

Well who says we need "perfect" time alignment? I know I can't hit the output time points EXACTLY through integer interpolation, meaning that no integer interpolation of the input data on the Fs_in chart will provide the exact audio samples that correspond precisely to the exact points, in time, on our Fs_out chart. BUT, I can get arbitrarily close This is the essence of ASynchronous Sample Rate Conversion.

So here's what I'm going to do. Conceptually, I will interpolate the input data by a pretty huge number (we'll be more specific very soon) ... in fact, by a pretty huge INTEGER number, so that I effectively "fill in" very many samples in-between the original Fs_in samples. I know, because we're talking asynch, that when an output "tick" comes along at Fs_out, I will not be able to provide an interpolated input sample that corresponds to that exact point in time ... so what if I just provide the most recently interpolated sample that I calculated instead? How BIG will the error be?

It's the nature of ANY bandlimited signal that, the more I interpolate the data ... or "fill in" data points between the original Nyquist points ... the LESS difference there will be between samples. And in fact, the more I interpolate, the smaller the error will be, by choosing the WRONG sample .... !!!!

I know how disturbing this sounds. But we must remember a couple things : One, a bandlimited signal is NOT free to do whatever it pleases between Nyquist samples ... in fact, it's pretty smoothly varying between those samples. And two, the more samples we can calculate beyond the Nyquist rate, through a very accurate interpolation process, the more adjacent samples will look the same. These are simple, indisputable facts of life

But no matter what, grabbing the most recently calculated interpolated sample, instead of the exact sample required at Fs_out, will introduce error. The question is ... How far do I have to interpolate, by what integer, so that grabbing the most recent sample will give me acceptably LOW error ??? We can never achieve perfection here, but we can get ARBITRARILY CLOSE ... simply because the higher I interpolate, the lower the error

Let's pause for questions This is a big point to digest. Next post will fully develop the conceptual model, and provide a way to calculate the error from "grabbing the most recently interpolated sample" when an Fs_out tick comes along.
  Reply With Quote
Old 26th February 2004, 09:25 AM   #24
hifiZen is offline hifiZen  Canada
diyAudio Member
hifiZen's Avatar
Join Date: May 2001
Location: Mountain View, CA
Welcome to the forum, werewolf! I look forward to some serious nitty-gritty technical discussion of audio DSP on here...

...It will be the ultimate intent of this thread to compare and demonstrate the superiority of this technique to option #1.
I've been waiting for someone to back me up on this one... I've always known it to be true, but many among the hi-fi crowd seem to have a phobia of some sort regarding FIR filters of the sin(x)/x function, including both oversampling and async. rate conversion varieties. A common argument against sin(x)/x filters is that they cause 'pre-ringing'... obviously somebody simply looked a the impulse response, and declared that such filters were unfit for audio use. Personally, I think the sin(x)/x function is one of the most beautiful pieces of math I've ever worked with. I have some related discussion for you on this topic later... specifically with regard to ripple in the passband (think inverse Fourier)...

Not to spoil your lesson, werewolf, and I'm sure you're already aware of this, but there's a nice little discourse on polyphase sin(x)/x filters for async. rate conversion in the AD1890 datasheet... you may wish to refer to it's illustrations... The actual explanations contained in the datasheet will certainly need further clarification for those forum members who are not as familiar with the mathematics and jargon of DSP.

ALL of the high frequency residual image energy must fold back down during decimation, because it's gotta end up in half the sample rate. Knowing this, what's the best stopband "shape" for the ASRC interpolator? Hint : it's NOT the flat, equi-ripple response you see with most DAC interpolators or ADC decimators. Flat stopband does NOT minimize total stopband energy ... but that's exactly what you need for ASRC.
I should think not, though you've got me noodle-scratching now about what windowing function will give the best combination of passband flatness and stopband rejection... hmm. Blackman?
- Chad.
  Reply With Quote
Old 26th February 2004, 11:36 AM   #25
Prune is offline Prune  Canada
Account Disabled
Join Date: Mar 2003
Location: Vancouver
I'm only familiar with frequency domain in regards to images, which are 2D. The Fourier Transform there is also 2D, with real and imaginary axes, and is often represented, a la Euler, in a frequency and phase coordinate system.
Since the audio signal is 1D, I'm assuming that so is its FT? My question is then, what bearing the phase in an audio signal has on the time/frequency representation.
  Reply With Quote
Old 26th February 2004, 02:30 PM   #26
werewolf is offline werewolf  United States
diyAudio Member
Join Date: Feb 2004
Location: Austin, TX
hey guys, some great feedback once again Let's address some questions, before we continue :

hifiZen - thanks for the welcome! DSP is a passion of mine Let's address a VERY significant point, still causes endless debate. We need to separate out two issues : pre/post ringing, and pre/post echo. These are two VERY distinct issues, but the distinction is a bit tricky to observe in the time domain.

Pre/post ringing : most obvious in the classic step response of a steep, linear phase (usually FIR) filter. Often thought to be a bad thing, for some reason. But any arguments suggesting that this response is bad, are fundamentally flawed ... certainly a topic for another thread! Let me just say now, for the record, that the pre/post ringing we often encounter in digital audio is nothing more than an artifact of the Gibbs phenomenon ... which simply states that abrupt transitions or discontinuities in one domain, cause ringing in the other. Bandlimited systems unfortunately fit in this category ... and there is no better example of a SHARPLY bandlimited system than digital audio. Don't like the ringing? Sure we can eliminate it ... but the price you pay will be aliasing, pure & simple ... no way around it And that's a BAD tradeoff.

Pre/post echo : Alot more subtle. A duality in the Fourier Transform can be invoked to show that passband RIPPLE ... a non-ideal filtering effect most commonly associated with FIR filters ... causes some slight echo in the time domain (kinda like very, very faint ghosts in analog TV images). This effect is NOT fundamental to digital audio, unlike pre/post ringing above. It can be driven to very low levels with long FIR filters, or avoided altogether with classes of maximally flat IIR, or (VERY long) maximally flat FIR filters. Again, probably a topic for another post! I sure look forward to it

Polyphase filters ... we're gonna talk about these very soon, in this very thread! I'll check into that AD stuff, see if I can find some useful images Shortly we'll introduce the concept of a "Polyphase locked loop" in this very context of Asynchronous Sample Rate conversion. It's the key to understanding how ASRC's respond to jitter

Stopband rejection : Of course, we want a flat passband for any rate conversion. But I've hinted that a flat or equiripple stopband is a very bad choice ... at least in the sense that you can do MUCH better, for the same length FIR filter. What you need for an Asynch SRC is minimal TOTAL stopband energy. Now you can research alot of technical papers about minimizing different "norm" functions in the stopband ... but it turns out that a stopband roll-off (not flat) of just about 6dB per octave will minimize stopband energy Heck I've always maintained that such a stopband shape makes better sense even for DAC interpolation filters, but sometimes it's hard to overcome industry standards Oh well, maybe even yet ANOTHER thread one day

Prune - An audio signal is "one dimensional" in the sense that the time axis has only one dimension. As you pointed out, this is different than, for example, an image signal, because the spatial plane on which images are represented is of course "two-dimensional". However, the Fourier Transform of even a 1-D signal is a COMPLEX function of frequency. Meaning that the Fourier Transform has a magnitude function vs. frequency, AND a phase function vs. frequency (or, alternatively, a REAL function vs. frequency and an IMAGINARY function vs. frequency ... but most people in the audio biz are more comfortable thinking about complex numbers in magnitude/phase form, rather than real/imaginary form... most likely due to the ear's relatively low sensitivity to absolute phase).

Gotta run for a second ... but I'll be right back because I'm not happy with my response to dddac's posts ...
  Reply With Quote
Old 26th February 2004, 03:13 PM   #27
werewolf is offline werewolf  United States
diyAudio Member
Join Date: Feb 2004
Location: Austin, TX
Alright, like I said I'm not happy with my response to dddac

So let me take a moment to distinguish between two different terms, as I use them :

Asynchronous re-clocking or re-sampling : this term describes a pretty simple operation where a digital audio signal is simply re-clocked by a clock from a different timebase. There is no interpolation or rate conversion performed on the signal, to support the re-clocking. In fact, a separate integrated circuit may not even be needed to support this operation.

It can be shown that this operation is really a degenerate form of Asynchronous Sample Rate Conversion ... one where "the most recent sample is grabbed" when an Fs_out tick comes along, but there has been no interpolation done to minimze the resulting error. It is therefore, a degenerate form of Asynch Sample Rate Conversion where the interpolation ratio is simply 1.

This seems to me to be a bad practise in any case imaginable. The error will be SUBSTANTIAL ... in fact the math we will develop in this thread will show how bad In the frequency domain, the sidebands around a fundamental tone will be HUGE. Of course, how closely the sidebands "bunch around" the fundamental will be a direct consequence of how close the two sampling rates are.

Asynchronous Sample Rate Conversion : this is categorically different, in the sense that SIGNIFICANT interpolation is performed on the Fs_in signal to minimize error (both time & freq domain) when the ultimate decimation to Fs_out occurs. Example chips that can perform this function are the CS8420, AD1896 (and their brethren). There may be a few others, but the point is that you can't force this operation on chips that are not intended to support it. The CS8412/8414 are most definitely NOT Asynchronous Sample Rate Converters ... they PROVIDE output clocks recovered from data streams, whereas ASRC's ACCEPT output clocks (from a local crystal oscillator). Most digital filters used for DAC interpolation are NOT ASRC's themselves ... although they can work just fine in ASRC environments, provided they are preceeded by CS8420, AD1896, etc.

I am wondering if any of dddac's spectra are the result of Asynchronous re-clocking/re-timing/re-sampling, rather than Aynchronous Sample Rate Conversion.

dddac ... may I ask you to provide more details, maybe even schematics, of the circuitry used to generate those spectra? Please understand, I mean no disrespect ... just hoping to learn more myself !
  Reply With Quote
Old 26th February 2004, 03:24 PM   #28
Petter is offline Petter
diyAudio Member
Join Date: Jan 2001
Location: Scandinavia

Let's for a minute assume that I have n current output DAC's in parallel which run without digital filtering.

If I time-shift each of the n units by one or several master clock cycles and add the outputs together, I end up with a low pass filtered result of sorts by nature of averaging and moving spectrum higher.

I was wondering if there is a way to figure out how to connect these together in order to achieve optimal results on output (would probably be different if current out dac's use internal digital filtering).

So a sequence could look like these (number used is number of parallell DAC units per time position):










How do I figure out what is optimal if I head down this route? I suppose this is exactly a digital filtering problem, and I should have paid more attention + taken different classes in school in order to understand how to select pattern and time steps.
  Reply With Quote
Old 26th February 2004, 09:20 PM   #29
guido is offline guido  Netherlands
diyAudio Member
guido's Avatar
Join Date: Mar 2002
Location: diepe zuiden

This looks a bit like some other stuff here. There was a post on a cambridge cd3 with 4 tda's in parallel. 4 fs filter before them and each dac got different data like this (i THINK, not shure!):

dac1 data current sample
dac2 data previous sample
dac3 data two samples back
dac4 data three samples back.

Done with 166 shift registers. The current outputs are connected together. So each datasample is 'used' four times in the output signal at different times. Claimed to be a 16x oversampling player.

Would this beneficial? I could modify a DAC, i'm working on, quite easily to do the same with two DAC's (it has no dig filter).
So 2x oversampling in total. Maybe i'll test it (GAL reprogramming).

If the above has nothing to do with the discussion here, i appologise!

  Reply With Quote
Old 26th February 2004, 10:20 PM   #30
ojg is offline ojg
diyAudio Member
Join Date: May 2003
Location: Norway
Hi werewolf!

Excellent thread! By far the best I have seen here in a long time!
But now is when the tricky part comes, can't wait to see!
  Reply With Quote


Asynchronous Sample Rate ConversionHide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
PMD100 Max Sample Rate? Filburt Digital Source 7 23rd May 2008 04:30 AM
Sample rate into BB PCM1798? Asgard Digital Source 14 22nd July 2006 12:54 PM
DSO Bandwidth vs sample rate bzo Parts 3 23rd February 2004 03:53 PM
New sample rate converters from TI hifiZen Digital Source 3 15th March 2003 11:42 PM

New To Site? Need Help?

All times are GMT. The time now is 02:51 AM.

Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 15.00%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
Copyright ©1999-2019 diyAudio