IPB

Welcome Guest ( Log In | Register )

2 Pages V  < 1 2  
Reply to this topicStart new topic
Anti-jitter RAM buffer in DACs, Which have one ?
TrNSZ
post Aug 6 2003, 15:57
Post #26





Group: Developer
Posts: 717
Joined: 25-September 01
Member No.: 20



To clarify on the "Monarchy Audio" DIP Digital Processor issue, I merely mentioned it because I had seen it available (and installed in the shop systems) at local audiophile shops. I haven't auditioned the unit, ABX'd it, or anything like that. Just merely stating that it exists and is supposed to eliminate jitter. =)
Go to the top of the page
+Quote Post
F1Sushi
post Aug 6 2003, 16:20
Post #27





Group: Members
Posts: 158
Joined: 30-August 02
Member No.: 3236



QUOTE (TrNSZ @ Aug 6 2003, 10:57 AM)
To clarify on the "Monarchy Audio" DIP Digital Processor issue, I merely mentioned it because I had seen it available (and installed in the shop systems) at local audiophile shops.  I haven't auditioned the unit, ABX'd it, or anything like that.  Just merely stating that it exists and is supposed to eliminate jitter. =)

I didn't really take your post as an endorsement - and thanks for mentioning it. I noticed one of these units went on eBay for $100 recently...
Go to the top of the page
+Quote Post
2Bdecided
post Aug 6 2003, 16:32
Post #28


ReplayGain developer


Group: Developer
Posts: 5254
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



In the current (September!) issue of Hi-Fi News (UK magazine) there is mention of a device which is manufactured by these people:

http://www.jitter.de/

The website answers a lot of the questions in this thread, though obviously they are trying to sell you their device.


The only objective error is here:

QUOTE
An ASRC (asynchronous sample rate converter) such as the AD1890 (go to the datasheet.pdf) from Analog Devices (a semiconductor manufacturer) is a great tool for converting sample rates.

If it had not been invented you would have to do a DA conversion and an AD reconversion with the required sample rate in order to accomplish a sample rate conversion. This would heavily degenerate your signal quality.


That's nonsense. asynchronous SRCs embed the jitter into the output, but synchronous SRCs (all software non-realtime solutions are effectively synchronous) do not. However, it's not relevant to the jitter discussion - it just shows they don't fully understand the area they are working in, or at least didn't feel the need to put fully correct information on their website.


They don't mention ABX testing - merely "subjective" results. I'm sure that won't please a few people here. However, the objective graphs and measurements are interesting.

If you have any interest in any of the questions in this thread, you should read through the whole website.

Cheers,
David.
Go to the top of the page
+Quote Post
F1Sushi
post Aug 6 2003, 16:42
Post #29





Group: Members
Posts: 158
Joined: 30-August 02
Member No.: 3236



QUOTE (2Bdecided @ Aug 6 2003, 11:32 AM)
The only objective error is here:

QUOTE

An ASRC (asynchronous sample rate converter) such as the AD1890 (go to the datasheet.pdf) from Analog Devices (a semiconductor manufacturer) is a great tool for converting sample rates.

If it had not been invented you would have to do a DA conversion and an AD reconversion with the required sample rate in order to accomplish a sample rate conversion. This would heavily degenerate your signal quality.


That's nonsense. asynchronous SRCs embed the jitter into the output, but synchronous SRCs (all software non-realtime solutions are effectively synchronous) do not. However, it's not relevant to the jitter discussion - it just shows they don't fully understand the area they are working in, or at least didn't feel the need to put fully correct information on their website.

Thanks for the link, David. BTW, never underestimate the power and wisdom of marketing folks to squew, distort, and sometimes just plain misrepresent science and legitimate innovation.

Marketing: Where the rubber meets the sky.
Go to the top of the page
+Quote Post
Halcyon
post Aug 6 2003, 19:25
Post #30





Group: Members
Posts: 244
Joined: 6-November 01
Member No.: 416



2Bdecided,

do you know of studies/measurements analysing asynchronous sample rate conversion embedded jitter effects?

What I mean that if the incoming bitstream has different kinds of jitter (statistically random, uncorrelated with signal OR data correlated), then what kind of effects does this have on the output signal?

What I've read is the common "it becomes part of the noise floor" explanation (referring to jitter).

However, I'm not sure this would be the case with data correlated jitter.That is, jitter becoming random noise and not signal correlated distortion for example.

Do you have any information on that?

I haven't been able to find any.

I'd suspect that any (usu. small) increase in noise floor would be perceptible benign compared to data correlated distortion.

regards,
Halcyon
Go to the top of the page
+Quote Post
F1Sushi
post Aug 6 2003, 19:44
Post #31





Group: Members
Posts: 158
Joined: 30-August 02
Member No.: 3236



QUOTE (Halcyon @ Aug 6 2003, 02:25 PM)
However, I'm not sure this would be the case with data correlated jitter.That is, jitter becoming random noise and not signal correlated distortion for example.

Just a side-note: Data-correlated jitter may be less and less of a problem as time goes on and PLLs improve. It is not uncommon now for PLLs to use only the incoming stream preamble (which is not data dependant) to maintain lock. Definitely still worth having a discussion on data-correlated jitter and it's effects, though...
Go to the top of the page
+Quote Post
Pio2001
post Aug 6 2003, 21:19
Post #32


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



You can always record an SPDIF output with an SB live, like this :



Beware that the loss seen here is not caused by embedded jitter, but by clock shift.

Another effect of clock shift : difference between a synchronous digital copy and an analog copy (obviously asynchronous) :



They are in synch at the vertical bar, where they cancel each other.
Go to the top of the page
+Quote Post
Patsoe
post Aug 7 2003, 08:30
Post #33





Group: Members (Donating)
Posts: 591
Joined: 11-February 03
From: UK
Member No.: 4952



QUOTE (F1Sushi @ Aug 6 2003, 03:34 PM)
QUOTE (Patsoe @ Aug 6 2003, 10:22 AM)
Actually, from the description I'd suspect it does sample rate conversion. That is, from some sample rate to the same sample rate, but through the method of sample rate conversion.

Doesn't look like it, according to some of their info...

"...It does NOT change the sampling rates."

Yes, I noticed they said that. But on the introduction page they also say "The original clock retrieved from the transport is abandoned. " One of these statements must not totally be accurate, since they're not fully compatible, right?
So, I figured then, they meant by "not changing the sample rate" that it outputs the same nominal rate.
QUOTE (2Bdecided @ Aug 6 2003, 04:32 PM)
...That's nonsense. asynchronous SRCs embed the jitter into the output, but synchronous SRCs (all software non-realtime solutions are effectively synchronous) do not.

In it's most basic form, ASRC ofcourse embeds all jitter into the output. But I've been told that recent ICs doing ASRC manage quite high jitter attenuation before conversion. The upper limit to this is ofcourse imposed by the requirement that it be done in real-time; apart from that, it could theoretically be as precise as software conversion.
Go to the top of the page
+Quote Post
F1Sushi
post Aug 7 2003, 12:46
Post #34





Group: Members
Posts: 158
Joined: 30-August 02
Member No.: 3236



My take on it is that the statement about "abandoning the clock" is probably marketing-speak. One of the reviews goes into a bit more "detail"...

"Between the decoupling transformers, a high speed receiver/transmitter chip feeds a professional 'repeater' that demodulates the incoming S/PDIF signal into respective clock and data lines which are then separately re-encoded and clocked-out via a highly stable oscillator."

This same blurb was used in a couple reviews, and was probably produced by the manufacturer. Sounds like a classic decoder/encoder (no data manipulation, thank god) with a PLL ("highly stable oscillator") doing the dirty work. I certainly doubt that they would attempt any SRC - I really think this is just a re-clocker (remember their "conditioning/boosting/isolation" function description) which they recommend placing no more than a few feet away from the receiver. The PLL is the "conditioner", the line driver is the "booster", and the decoupling transformer is the "isolator".

Thoughts?

Edit: corrected "decoder/encoder", was "encoder/decoder"

This post has been edited by F1Sushi: Aug 7 2003, 13:11
Go to the top of the page
+Quote Post
Patsoe
post Aug 7 2003, 15:23
Post #35





Group: Members (Donating)
Posts: 591
Joined: 11-February 03
From: UK
Member No.: 4952



QUOTE (F1Sushi @ Aug 7 2003, 12:46 PM)
Thoughts?

Well, I've only one further thought on this: how can people buy this product when it has such a fishy website? There's a lot of marketing blabla but so little real information, that it leaves us to guess what we're buying there. And apart from that, they never read more than a very basic HTML primer it seems (mildly wandering off-topic here...).

I suppose you're right about it not being a SRC. I didn't click through to the reviews at first.
Go to the top of the page
+Quote Post
2Bdecided
post Aug 7 2003, 15:36
Post #36


ReplayGain developer


Group: Developer
Posts: 5254
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



QUOTE (Patsoe @ Aug 7 2003, 02:23 PM)
QUOTE (F1Sushi @ Aug 7 2003, 12:46 PM)
Thoughts?

Well, I've only one further thought on this: how can people buy this product when it has such a fishy website?

What, the one I posted? www.jitter.de? Oh the answer's simple - they'll buy it because it's had a good review in a Hi-Fi magazine.

And everything on the site seems to be scientifically valid.


I just had an interesting email from Frank Klemm about ASRCs in movie playback. He says... (I'll remove it if it turns out that I wasn't supposed to forward this here!)

QUOTE
The sync engine has the task to display and play the decoded stuff.
There are three problems:

  - the Video Card typically don't run with a multiple of (actually not
    exact known) frame frequency
  - The audio device typically don't run on the exact frequency which is
    setup
  - There are displacements between the time calculated from the
    samplerate * samplecount and the time stamps.


Sources of this errors are:

  - sound card and video card are derived from different quartz oscillators
  - noone really cares about exact frequncies, a 100 Hz frame rate can be
    99.253536 as well as 101.8378626 Hz, a 48000 Hz can be a 48662.06896 Hz
    (SB 128 PCI)
  - rounding and accumulated errors due to time quantization (typically
milliseconds)
  - errors in A/V streams
  - the typically view "It nearly works, why should I improve it"
  - the typically "100 implementations and every is a little bit different"


Typically the video display engine has a simple job and only waits until the
time of a video timestamp is reached, then wait again until the CRT video
frame is finished and then switch to the next image.

The audio engine typically uses some called a "asyncronous sample rate
converter" or "Software PLL" which converts the audio stream to the sample
rate of the output device. This includes:

  - estimation of the *real* sample rate of the output device
  - estimation of the *real* sample rate of the input stream
  - very smoothly adjusting small difference changes between these two frequencies
  - adjusting medium difference changes between these two frequencies
  - immediately adjusting large difference changes between these two frequencies

This is typically done by a control signal which is derived from the samples
in the sample fifo buffer. The sample count is normally lowpass filtered by%xact frequncies, a 100 Hz frame rate can be
    99.253536 as well as 101.8378626 Hz, a 48000 Hz can be a 48662.06896 Hz
    (SB 128 PCI)
  - rounding and accumulated errors due to time quantization (typically
milliseconds)
  - errors in A/V streams
  - the typically view "It nearly works, why should I improve it"
  - the typically "100 implementations and every is a little bit different"


Typically the video display engine has a simple job and only waits until the
time of a video timestamp is reached, then wait again until the CRT video
frame is finished and then switch to the next image.

The audio engine typically uses some called a "asyncronous sample rate
converter" or "Software PLL" which converts the audio stream to the sample
rate of the output device. This includes:

  - estimation of the *real* sample rate of the output device
  - estimation of the *real* sample rate of the input stream
  - very smoothly adjusting small difference changes between these two frequencies
  - adjusting medium difference changes between these two frequencies
  - immediately adjusting large difference changes between these two frequencies

This is typically done by a control signal which is derived from the samples
in the sample fifo buffer. The sample count is normally lowpass filtered by
three ... five saturating lowpasses.

    filter_effect            = function ( lowpass_filtered_signal - input_signal)
    lowpass_filtered_signal *= ( 1 - filter_effect )
    lowpass_filtered_signal += filter_effect * input_signal

function (x) may be something like:

    function (x) = ( x*x ) / (1 + x*x)

This suppresses high frequency jitter which may be audible.

--
Frank Klemm



Cheers,
David.
Go to the top of the page
+Quote Post
F1Sushi
post Aug 7 2003, 15:42
Post #37





Group: Members
Posts: 158
Joined: 30-August 02
Member No.: 3236



QUOTE (2Bdecided @ Aug 7 2003, 10:36 AM)
QUOTE (Patsoe @ Aug 7 2003, 02:23 PM)
QUOTE (F1Sushi @ Aug 7 2003, 12:46 PM)
Thoughts?

Well, I've only one further thought on this: how can people buy this product when it has such a fishy website?

What, the one I posted? www.jitter.de? Oh the answer's simple - they'll buy it because it's had a good review in a Hi-Fi magazine.

Oops - no, it was for this product...but the same magazine review endorsement psychology no doubt still applies.

http://www.monarchyaudio.com/DIP.htm

This post has been edited by F1Sushi: Aug 7 2003, 15:59
Go to the top of the page
+Quote Post
ChristianHJW
post Aug 7 2003, 16:01
Post #38


Matroska developer


Group: Members
Posts: 922
Joined: 29-September 01
Member No.: 74



This thread confirms a couple of opinions i have since quite some time now :

1. A well tuned CD player, with drive speed controlled by the DAC timer/buffer does always ( say, in most cases ) sound better then external drive / DAC combo's, however expensive they might be

2. SPDIF sucks in terms of preserving highest possible quality ( its practical, easy to handle, but thats about it )

3. MISSION people knew what they were doing when inventing a new digital interface ( no SPDIF on these devices ) for their hi-quality CD drive / DAC combo's , with good old handshake signals to sync the timing wink.gif ....


--------------------
Support matroska - the bestest vapourware project ! http://www.matroska.org
Go to the top of the page
+Quote Post
Patsoe
post Aug 7 2003, 18:56
Post #39





Group: Members (Donating)
Posts: 591
Joined: 11-February 03
From: UK
Member No.: 4952



QUOTE (ChristianHJW @ Aug 7 2003, 04:01 PM)
...
3. MISSION people knew what they were doing when inventing a new digital interface ( no SPDIF on these devices ) for their hi-quality CD drive / DAC combo's , with good old handshake signals to sync the timing wink.gif ....

Yes, this is something I really don't understand about "high-end" hardware brands. Such two-way traffic not only provides best results, but it is also much cheaper and easier to design. Since it (presumably) sounds better, they could still sell it at the same pricepoint at which transports-with-ultra-hyper-cool-stabilized-clocks and DACs-with-four-stages-of-PLL are sold nowadays, while saving themselves a lot of hassle.
Go to the top of the page
+Quote Post
Halcyon
post Aug 7 2003, 20:09
Post #40





Group: Members
Posts: 244
Joined: 6-November 01
Member No.: 416



Shhh... don't tell them. It's reserved for the professional studio market smile.gif

regards,
Halcyon
Go to the top of the page
+Quote Post
F1Sushi
post Aug 7 2003, 20:42
Post #41





Group: Members
Posts: 158
Joined: 30-August 02
Member No.: 3236



Just came across this link, which raises several topics brought up over the past few posts, including

1. SPDIF reclocking (confirmed my fears).
2. I2S (3-wire) clocking scheme for separates.
3. DAC clock sourced timing for separates (my preference, as it closely emulates the 1-box architecture from a clock-distribution perspective).

http://www.republika.pl/mparvi/digital.htm

Not sure about the source, but I can't argue with the facts presented. Perhaps the presented state of the art wrt decoder jitter attenuation is a bit dated, but I think we would all sleep better if integrated PLLs were a bit better at suppressing LF jitter...
Go to the top of the page
+Quote Post
2Bdecided
post Aug 8 2003, 09:51
Post #42


ReplayGain developer


Group: Developer
Posts: 5254
Joined: 5-November 01
From: Yorkshire, UK
Member No.: 409



This thread should be in the FAQ!

Cheers,
David.
Go to the top of the page
+Quote Post
F1Sushi
post Aug 8 2003, 16:36
Post #43





Group: Members
Posts: 158
Joined: 30-August 02
Member No.: 3236



Here's a Monarchy Audio DIP on a chip:

http://www.cirrus.com/en/products/pro/detail/P51.html

Just decode the incoming AES3 stream, recover and dejitter the clock, and use same to drive the AES3 output interface.

The 3-wire I2S interfaces are gravy...
Go to the top of the page
+Quote Post
d_kay303
post Aug 14 2003, 08:44
Post #44





Group: Members
Posts: 19
Joined: 11-August 03
Member No.: 8304



QUOTE (ChristianHJW @ Aug 7 2003, 07:01 AM)
This thread confirms a couple of opinions i have since quite some time now :

1. A well tuned CD player, with drive speed controlled by the DAC timer/buffer does always ( say, in most cases ) sound better then external drive / DAC combo's, however expensive they might be

2. SPDIF sucks in terms of preserving highest possible quality ( its practical, easy to handle, but thats about it )

3. MISSION people knew what they were doing when inventing a new digital interface ( no SPDIF on these devices ) for their hi-quality CD drive / DAC combo's , with good old handshake signals to sync the timing wink.gif ....

I did some simple pen and paper exercise, and this is what I found out:

Let's say our CD-player reads twice as slow as our DAC reads from FIFO buffer.
Datastream is a,b,c,d bits)

clock
CD__DAC__BUFFER (3bit)
1___Pause__000
2_________00a
3_________0ba
4_________cba
5____1 ____0cb
- ____2____ 00c
6____3 _____00d
-____4_____000
7____5 _____000 (bit e just makes it!)
-____6_____000 underrun!

Let's say our CD-player reads twice as fast as our DAC reads from FIFO buffer.
Datastream is a,b,c bits. We have 4 bit's FIFO


clock
CD__DAC_ BUFFER (4bit)
1___Pause_000
2________000a
3________00ba
4________0cba
5___1____0dcb
6________edcb
7___2____fedc
8________buffer overrun!


Ok, so what, no CD player works this way. They're not that stupid.

BUT.. say the clock in the CD-player would be 0.00001% slower or faster, eventually it would either underrun or overrun. Even if it's unstable being sometimes faster sometimes slower(jitter) it would have a meantime that is either slower or faster, and that will also eventually overrun/underrun the buffer. So what to do?, well.. two way communication would be nice. I guess most CD-player adapt their reading speed with regards to how full their FIFO buffer is.

How big is this problem in real life?, no idea. I think I'll buy an external USB DAC to my computer when there is a good one available.

This post has been edited by d_kay303: Aug 14 2003, 08:50
Go to the top of the page
+Quote Post
Patsoe
post Aug 14 2003, 09:25
Post #45





Group: Members (Donating)
Posts: 591
Joined: 11-February 03
From: UK
Member No.: 4952



You're pointing out the exact reason why a two box transport/DAC combo has jitter problems: you can't afford buffer underruns, since even the most unmusical listener will hear that.
So, when an spdif link is used, DACs don't use their own free running clock; instead, they have a clock that can follow the transport's clock. This is an ugly process: the perfect square wave that the transport's clock may well have is lost in the long way to the DAC; there's non-ideal cabling, noise, intermodulation between data and clock signals, and lots more. The DAC then, is not following a perfect clock at all!
So you see, 'in real life', buffer over/underruns are not a big problem. But precluding those problems causes this other problem.

As to one box cd-players: the rate at which their transport reads is controlled by the same clock signal as the DA-rate. By principle, the fifo will always be filled then. The purpose of a fifo here, isn't in the first place to buffer reading speed variations, but to cope with the fact that bits don't all have the exact same length on the CD surface.
Go to the top of the page
+Quote Post
Pio2001
post Aug 14 2003, 12:17
Post #46


Moderator


Group: Super Moderator
Posts: 3936
Joined: 29-September 01
Member No.: 73



As 2Bdecided explained, this is only valid for cheap DACs. Good DACs filters the incoming jitter in such a way that the master clock is the DAC's one and not the CD Player's one.
The trick is that the DAC's master clock is allowed to drift very slowly in order to compensate for buffer variations. Ideally the buffer is 50 % full. If it becomes >50% full, the master clock is speeded up very smoothly in order to go back to 50%, and if it becomes less than 50% full, the clock is slowed down.

In conclusion, we still don't know which kind of players have a variable clock in order to lowpass the incoming jitter, and which ones directly slave themselves to the incoming stream, but we have another problem in addition, we don't even know if there is an audible difference between the two technologies .

By the way, I don't think that the time spent by a DAC to output audio after a digital stream is fed gives any useful indication. For example the Sony DTC 55ES is a DAT deck. The DAC takes from 0.5 to 1.0 seconds to output audio after a sample rate change. But the device produce an audible clic when it's done. This clic comes from an internal switch that turns the analog output on/off. The same clic is heard 4 seconds after the device is turned on, because a delay is set at startup, before the outputs are enabled, exacly like for many power amplifiers.
Thus the time took by a DAC to output sound when a digital stream is plugged on might depend on the delay setup for the analog output muting, that can have nothing to do with the time needed to synchronize with the incoming stream, or I'd rather say, that is setup long enough for the digital stream to be in sync long before the analog output is unmuted. How much long before is up to the engineer who designed the circuitry.
Go to the top of the page
+Quote Post

2 Pages V  < 1 2
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st November 2014 - 20:38