Digital Receiver Chips

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Rate estimator is used when you need the sampling rate to be changed. That has nothing to do with jitter elimination.
Let's not "mix" in discution the two fuctions - jitter elimination and sample rate conversion.
I cannot understand a digital loop that would perform a jitter elimination without some memory to compensate for the jitter induced difference in frequency.
If you don't have that memory, your loop NEEDS to be locked into the incoming signal, and that will not eliminate the jitter.

I am still curious why only AD shows that clear the FIFO memory and the TI doesn't. If TI didn't use enough buffer memory, maybe that's why cannot implement jitter reduction. Maybe that's why Benchmark are saying what are saying...
That's interesting for me.
 
Last edited:
Rate estimator is used when you need the sampling rate to be changed.

Its always being changed unless you apply the same clock to both. Which kind of defeats the object of using an ASRC in the first place.

That has nothing to do with jitter elimination.
Let's not "mix" in discution the two fuctions - jitter elimination and sample rate conversion.

They're by no means separate, so let's not try to separate them.

I cannot understand a digital loop that would perform a jitter elimination without some memory to compensate for the jitter induced difference in frequency.

Sure enough, its your lack of understanding. The way to address that is by asking questions to clear that up. There's no shortage of informed people here who can help enlighten you. But while you continue to make statements as if you do understand people will stay away and you'll remain in ignorance. You decide :)
 
OK, inform me how you can ajdust for the incoming variations WHITHOUT a buffer memory.
The incoming data stream has a variable frequency in the range of X-j to X+j (X is the "proper" data freq/rate and j is the jitter).
The output freq is X - perfect, cristal derived.
At some point you will have less samples incoming (X-j) that you are trying to extract. At a latter moment you will have incoming more samples (X+j) than you are trying to extract (X).
In my view you have 2 choices:
1. You can average that +/- j fluctuation with a buffer memory. Read ahead algorithm - that is tried and tested in many places.
2. You can skip and double samples to make up the difference, using no buffer memory.

You seem to know a different, magical, way?
 
OK, inform me how you can ajdust for the incoming variations WHITHOUT a buffer memory.

Naturally enough, some kind of buffer memory is needed. Just nowhere near as much as you think is called for.

The incoming data stream has a variable frequency in the range of X-j to X+j (X is the "proper" data freq/rate and j is the jitter).

Well that application of math is misleading because jitter is measured in pS or nS (if its bad) and frequencies are in Hz. So it might be better to talk about the sample period as then both terms in the equation are time. With 44k1 the period is 22.676uS. If the peak jitter were 1nS @ 22k05 then a worst case time period sequence would be 22.675 - 22.677 - 22.675uS etc. At 1Hz jitter frequency still with 1nS peak jitter the period lengths would change more slowly over the course of 44,100 sample clocks. Nowhere has data built up sufficiently to need a buffer of more than one sample - that could only be called for if the jitter reached 22.6uS peak.

Note here that the jitter frequency is irrelevant to the buffer called for - its the peak jitter (i.e. the maximum deviation from ideal) which determines the buffer length. That's assuming there's no change in the input sample frequency - ASRCs do work when that's changing (for the Cirrus part they specify 10% change per S as the max).

In the case of an SPDIF receiver, the bit time is much smaller than the sample time, hence way lower jitter can be tolerated without a (1-bit wide) buffer.
 
Frequency is less confusing, but yes you can use period too. Period needs to be raported to the signal periord. A 5ns jitter for 44.1kHz is different from a 5ns jitter for 192kHz.
I think your logic is flawed. Jitter differences (expressed in time/periods) will add up over time. Incomming jitter can be up to 500ns (depending of transport).
IMO in order to clean it to a 10Hz resolution we need a buffer to store double of ALL those samples for the whole period (1/10 seconds), and keep it "filled" with data half way. Because in that 1/10 second, the jitter-affected data period can still be LESS or MORE that the Xtall controlled one.
In 1/10 second, at 96kHz sample rate, 24 bit, we have 2x96x1000x2x24/8=1125 kBytes=1.1 MBytes of memory.
Esoteric used 128Mbits of memory for 192kHz samplerate. That is 16MBytes.
Digital Lens was using 0.5MBytes for 44.1kHz/ 2 seconds.
And they say:
The Analog Devices AD1860 Asynchronous Sampling Rate Converter chip, the device at the heart of the Digital Domain VSP and Z-Systems jitter-reduction boxes, also has input and output clocks that are independent (that's what the "Asynchronous" means). The AD1890, however, changes the audio data by interpolating new samples between the input samples. At the output, the chip continuously throws out lots of unneeded samples to achieve the desired output sampling rate. Only a small percentage of the final output samples are identical to the input samples. What you put in isn't what you get out. The AD1890's output is jitter-free, but the sample amplitudes can be slightly different from what is required. The part takes in the right samples at the wrong time, and outputs the wrong samples at the right time.
 
Last edited:
I think your logic is flawed.

Sure. But you haven't shown any flaws so far.

Esoteric used 128Mbits of memory for 192kHz samplerate. That is 16MBytes.

Its obvious they used it for marketing purposes, not sound engineering.

The AD1890, however, changes the audio data by interpolating new samples between the input samples.

Duh! As Bruno Putzeys points out - an ASRC which didn't change the audio data would be a ****-poor one.

At the output, the chip continuously throws out lots of unneeded samples to achieve the desired output sampling rate.

Why would they be 'unneeded' ?:eek:

Only a small percentage of the final output samples are identical to the input samples.

Nonsense - if its working correctly and changing the sample rate, the chances of input samples being the same as output ones is very small indeed.

What you put in isn't what you get out.

Precisely! And that's a feature, not a bug.

The AD1890's output is jitter-free, but the sample amplitudes can be slightly different from what is required. The part takes in the right samples at the wrong time, and outputs the wrong samples at the right time.

And just what is 'required' ? A bit perfect copy of the original samples, but at different times? Who wrote this stuff?:D
 
SoNic:

In telecommunications, we are dealing with more than just audio. There are control codes, routing addresses and other such overhead which cannot be altered. In addition, many payloads, such as financial data and other records, also cannot be altered. Jitter usually is not a problem in telecom unless it is so extreme that it increases the system's bit-error-rate. All a FIFO need do is prevent jitter from doing that, which does not typically require a great deal of memory to accomplish. FIFO style buffering is usually adequate in such systems.

In audio, we are concerned about jitter well beneath that which can cause actual bit errors because of the data-conversion aspect of audio. Any amount of residual jitter will get converted into the frequency-domain as a distortion product. Which, by the way, is why jitter is more of a concern for cellular networks, satellite transponders, and the like, than it is for purely digital networks. Basically, anywhere there's a critical data-conversion aspect to the system which can be degraded by jitter based distortion products in the analog domain.
 
Last edited:
Agree.
That's why the audio digital chain can "make up" samples or let the jitter "go by". It's just distortion in the end, and at some point will below 16 or 20 or 24 bit TDH+N floor.

Problem is... how much jitter is too much? How much sample "guesstimation" is too much?

BTW I wonder if the LMK04000 can be used to "clean" the clock in the transport or it would be anyway a waste due to seek jitter?
 
Last edited:
Let's not get there... If you don't know the difference in voltage drop between #10AWG and #14AGW it doesn't mean it doesn't exist. And besides you dind't bring anything to discussion, just a straw man strategy :)
I think did told you once, I was raised with that, I am immune.
 
Last edited:
Let's not get there... If you don't know the difference in voltage drop between #10AWG and #14AGW it doesn't mean it doesn't exist.

I decided to use irony as a different kind of strategy to see if the penny would drop for you. It seems it still hasn't, but never mind. We can't obtain our lightbulb moments to order.

And besides you dind't bring anything to discution, just a straw man strategy.

I've done a fair bit of explaining where your arguments are flawed. But as you missed it, I'll stop now :D
 
CS8416 is of mediocre quality, DIR9001 is a lot better but I think Wolfson WM8805 is the best. It is the only one that has very low jitter specs and does reclocking too. There are very cheap modules onm Ebay with WM8805. I bought one to test the WM8805.

I know this is an ancient thread, but I was wondering if WM8805 is still the recommended one to get.

I am trying to figure out if I should buy another board or if I try to use one of my other DAC boards to get the I2S signals. For example, I have board with SA9023A on it and another with CS8416. I might be able to tap into those signals without damaging the board. But there would be no point if those are poor performance relative to a cheap WM8805 board.

I assume XMOS U208 is best. Would WM8805 be 2nd, DIR9001 3rd? I guess I am not looking at AKM right now due to availability. I tried to order AKM DAC boards twice but both orders were cancelled.

It has been explained that implementation, clocks and supplies will matter too. I am trying to strike a good balance between performance and expense.


Can you help me order this list by performance so that I know which boards to consider?


  1. XMOS U208
  2. WM8805
  3. DIR9001
  4. SA9023A
  5. CM6631A
  6. CS8416
In case the list is a little confusing I am primarily using SPDIF but I could switch to USB but that is not preferred. But before I decide on that I want to know about relative performance.
 
Last edited:
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.