The magic of buffers

[R1200CL]

Lately I have try to dig into the area of jitter free network audio transfer, and best method to ensure that this is happening. Here the use of buffers came up as the holy grail.

 

I been told by a member here that jitter https://en.m.wikipedia.org/wiki/Jitter can’t exist in buffers. https://en.m.wikipedia.org/wiki/Data_buffer

 

And no one has said otherwise, so I’m assuming this is a correct statement. 

So whatever jitter was present in your network chain, a buffer in the last piece of your chain will clean or remove whatever jitter and phase noise and different gremlins that may exist previously in your chain. 

 

This lead me think, why isn’t then buffers the answer to how to clean up jitter in any digital transfer ? It can’t be that simple ?

 

As an example, if all the Rendu’s had such buffers, (maybe they have?), shouldn’t they offer equal quality in SQ ?

Then the choice of internal clock shouldn’t matter either ? (Maybe why latest version of microRendu doesn’t have same clock as the more expensive Rendues, but same buffer). 

 

I (or someone else) must be mixing things here. What have I misunderstood ? Maybe there exist so many types of jitter, and that’s the confusing thing. 

[fas42]

1 hour ago, R1200CL said:

So whatever jitter was present in your network chain, a buffer in the last piece of your chain will clean or remove whatever jitter and phase noise and different gremlins that may exist previously in your chain.

 

This is where it goes astray ... changing the jitter characteristics at some point in the path is highly likely to change things, but is no guarantee that "all the gremlins" are got rid of  - you may merely add a new set of issues, by having a buffer, which effectively nulls the benefit of including one.

 

Jitter is not a universal evil - but in digital audio has become the great baddy, that has to be struck down at all cost 😁 - I've managed to obtain competent playback without being obsessed about the matter, 😉. As always, in audio the how well things are done is far more important, than merely ticking another box to try and convince oneself that things are under control ...

[barrows]

On 10/13/2020 at 2:20 PM, R1200CL said:

Lately I have try to dig into the area of jitter free network audio transfer, and best method to ensure that this is happening. Here the use of buffers came up as the holy grail.

 

I been told by a member here that jitter https://en.m.wikipedia.org/wiki/Jitter can’t exist in buffers. https://en.m.wikipedia.org/wiki/Data_buffer

 

And no one has said otherwise, so I’m assuming this is a correct statement. 

So whatever jitter was present in your network chain, a buffer in the last piece of your chain will clean or remove whatever jitter and phase noise and different gremlins that may exist previously in your chain. 

 

This lead me think, why isn’t then buffers the answer to how to clean up jitter in any digital transfer ? It can’t be that simple ?

 

As an example, if all the Rendu’s had such buffers, (maybe they have?), shouldn’t they offer equal quality in SQ ?

Then the choice of internal clock shouldn’t matter either ? (Maybe why latest version of microRendu doesn’t have same clock as the more expensive Rendues, but same buffer). 

 

I (or someone else) must be mixing things here. What have I misunderstood ? Maybe there exist so many types of jitter, and that’s the confusing thing. 

Ummm...  First of all, we would need ot specify what jitter you are referring to:

 

As you mention Rendu Series renderers, I guess you mean Ethernet jitter, and not digital audio jitter?

 

For Ethernet, at every step along an Ethernet pathway, any jitter is removed because indeed, the data is buffered, and then re-clocked out of that buffer.  So every device an Ethernet signal goes through buffers and re-clocks the data, every router, switch, modem, and fiber media converter buffers and re-clocks the data, removing any jitter from the incoming stream, and creating a new jitter free stream on the output.

 

So, every Ethernet component buffers the data, it has to, and this is one of the reasons why Ethernet can transfer data over such long distances without any issues.

 

Note, that jitter in an Ethernet stream has no relation at all to digital audio jitter in a DAC, that is an entirely different thing.

[R1200CL]

1 hour ago, barrows said:

So, every Ethernet component buffers the data, it has to, and this is one of the reasons why Ethernet can transfer data over such long distances without any issues.

 

Note, that jitter in an Ethernet stream has no relation at all to digital audio jitter in a DAC, that is an entirely different thing.

This is interesting. 

Cause if this correct, the choice of switch shouldn’t matter at all. 
 

1 hour ago, barrows said:

As you mention Rendu Series renderers, I guess you mean Ethernet jitter, and not digital audio jitter?

You’re correct. 
However the interaction (embedded?) between threshold jitter and phase noise in clocks in the various devices is interesting to understand, if it exist. 
 

I assume digital audio jitter also organizes partly from a clock, so I expect it somehow can be compared. 
 

Buffers as I understand it, also have jitter, in and out, and amount of jitter may depending one their size.
But I think jitter in buffers is very low. So whenever data moves, there will exist digital jitter I suppose. 

 

[fas42]

13 minutes ago, R1200CL said:

This is interesting. 

Cause if this correct, the choice of switch shouldn’t matter at all. 

 

 

Many things shouldn't matter ... but they do, 😁. Trouble is, no electrical, and electronic circuitry is perfect, and noise and artifacts can intrude in the area where they need to be kept out - either stop the misbehaviour of the electrical parts, or have the key areas extremely well isolated from poorly behaved electrical areas - or do both; the latter is usually the best, real world,  approach. A switch is an electrical device, and hence can cause trouble; just because the theory says it shouldn't, doesn't mean anything for an audio system, unless one has done some experiments to confirm that it has no effect.

 

13 minutes ago, R1200CL said:

 

You’re correct. 
However the interaction (embedded?) between threshold jitter and phase noise in clocks in the various devices is interesting to understand, if it exist. 
 

I assume digital audio jitter also organizes partly from a clock, so I expect it somehow can be compared. 
 

Buffers as I understand it, also have jitter, in and out, and amount of jitter may depending one their size.
But I think jitter in buffers is very low. So whenever data moves, there will exist digital jitter I suppose. 

 

 

I always assume that anything electrical in the area can cause a problem - take nothing for granted ... I have been caught too many times over the years by "silly things" making a difference - this is the path for getting value for money SQ: make sure that the thing you are sure can't affect the sound really doesn't affect the sound, by doing simple experiments with changing things.

[PeterSt]

On 10/13/2020 at 10:20 PM, R1200CL said:

And no one has said otherwise, so I’m assuming this is a correct statement.

 

That would be a little dangerous to assume. Point here is that if I'd want I could undoubtedly attest the same, put 8K bets on it and even pay for travel and expenses. However, one could also be

- not too deaf

- have an open mind with it

- try to examine how certain products have a right of existence (people buy it and it isn't returned)

- try to learn way (waaay) beyond text books and reason out what's actually happening (once passed the above).

 

Who says it is jitter in that switch (etc. etc. etc.) ?

It won't be. Still it definitely is the switch incurring for responses elsewhere in the electrical system (but don't listen too much to Frank 🤪).

 

So it's actually the other way around and I would surely attest that the differences are huge and I would bet the same person(s) 10K euros plus a nice dinner (when Corona permits) that he or she will drop a jaw on the floor because of this enormous difference. What I won't do, however, is pay for a system that makes this audible at their homes.

 

So no, it won't be jitter of the switch (therefore it will be pointless to come up with eye diagrams and the like); it will be what the device causes elsewhere. And it does it at the whatever rate it "operates" (read: the effect is at random but this effect will be quite the same for the same brand and type for everyone).

 

Let's say that I am a bit experienced with the XXHighEnd software. What does it do ? manipulate buffers-buffers-buffers. Yes, that is really all. What does it cause ? different DAC behavior regarding jitter. So yes, XXHE was explicitly made to do that. No vague Frank-story, just a story which is known for I forgot how many years.

Try to envision that all what the software can do is change the behavior of the PC. Some call it jitter in there, but this is rubbish. Still it is about electrical patterns (current draw) no matter how small and no matter how hard to believe (want more bets ?). And here too, like with a switch or anything, this ends up in the D/A converter and causes jitter patterns there.

 

Let's also not forget that from there (the software) I started working on DACs that could counteract this idiocy. Up to date (since 2010) I failed on that. It didn't matter with how many galvanic isolation means I came up with, always as a first (so there goes the "Ethernet" story for an important base not working (the isolation)). It just won't stop the backdoor influences.

 

Peter

[fas42]

Note Peter says what I say, 😉, but in a different way - the difference is that many like him are absolutely certain they know exactly what to do to make everything better - which may entail spending some money, 😜. I have no such certainties - there are many solutions out there for getting best sound ... because, every rig is unique, and what one needs to do to make a particular setup fire will largely be unique to that setup - and most certainly that will be the case if you wish to spend the least amount of money, 😉.

 

Just think of all high end rigs as being a custom effort; and therefore all sensible solutions for getting the best sound out of them will be, yes, custom ...

[John Dyson]

On 10/13/2020 at 4:20 PM, R1200CL said:

Lately I have try to dig into the area of jitter free network audio transfer, and best method to ensure that this is happening. Here the use of buffers came up as the holy grail.

 

I been told by a member here that jitter https://en.m.wikipedia.org/wiki/Jitter can’t exist in buffers. https://en.m.wikipedia.org/wiki/Data_buffer

 

And no one has said otherwise, so I’m assuming this is a correct statement. 

So whatever jitter was present in your network chain, a buffer in the last piece of your chain will clean or remove whatever jitter and phase noise and different gremlins that may exist previously in your chain. 

 

This lead me think, why isn’t then buffers the answer to how to clean up jitter in any digital transfer ? It can’t be that simple ?

 

As an example, if all the Rendu’s had such buffers, (maybe they have?), shouldn’t they offer equal quality in SQ ?

Then the choice of internal clock shouldn’t matter either ? (Maybe why latest version of microRendu doesn’t have same clock as the more expensive Rendues, but same buffer). 

 

I (or someone else) must be mixing things here. What have I misunderstood ? Maybe there exist so many types of jitter, and that’s the confusing thing. 

 

Technically, at the lowest levels, if you do a resynch with FIFO and reclock the data -- then the final clock accuracy & jitter determines the digital jitter.  A simple one level clocked buffer is good to get rid of low level clock jitter.   This hides the phase errors of previous clocks.

 

There can be sampling jitter where an original conversion from analog to digital also, but the effects of that jitter are forever some kind of noise in the signal.  There are some sophisticated methods that in certain cases, some jitter can be mitigated, but not usually at the generally small jitter  of a digital sampling clock.   Keep analog sampling windows constant and narrow, also keep clock phase noise/frequency accuracy tight.

 

For buffering different clock rates, a FIFO is a signal buffer, where if the input and output clock rate error accumulation is less than the size of the buffer, then that can be totally hidden.  This is the way that you can listen realtime to audio on the internet, and only get interruptions once in a while (when the internet is slow and the buffer empties.)

 

A common misunderstanding about 'clock jitter' is about there being apparent jitter caused noise in analog audio at the D/A conversion.   The fact is that most of the jitter caused noise (other than the direct clock for the D/A) is ground/conducted and some coupled noise that can leak in.   Jitter from before previous buffers cannot substantially leak through -- even due to the sampling window effect in slow D flip flops.   The noise created by that kind of window only happens on analog sampling.

 

So -- resynching different clock rates with a FIFO (or SW equiv), or the single buffer reclocking circuits are all magical and isolate the digital signal from other clocks.  Of course, there are some limitations in the extreme -- but no need to worry unless 1) something like a slow internet, 2) borked design.

 

* I am not at 100%, so I hope that I haven't overlooked something.

John

 

 

 

[Superdad]

What seems to be missed in most of these discussions is that what is going on for these packet data interfaces is that jitter/phase-noise (from ALL the chips, etc.) is a cause, not an effect.  It transfers and along the way is creating ground-plane noise/bounce, which in turn creates threshold jitter for subsequent circuits--ultimately through to the DAC.

 

Please reread our paper (and the technically knowledgable can ignore our attempts to simplify/explain the more basic concepts) and look for the core of what we are explaining:

 https://cdn.shopify.com/s/files/1/0660/6121/files/UpTone-J.Swenson_EtherREGEN_white_paper.pdf?v=1583429386

 

[R1200CL]

3 hours ago, Superdad said:

It transfers and along the way is creating ground-plane noise/bounce, which in turn creates threshold jitter for subsequent circuits--ultimately through to the DAC.

And of cause, it also applies to fiber transfers. 

So you have

1) Jitter carried through digital data,  but the advantage with fiber is that 

2) Leakage current, won’t occur (from one device to next). 
 

I think (hope) pictures below illustrates what John writing about:

 

 

[jabbr]

4 hours ago, Superdad said:

What seems to be missed in most of these discussions is that what is going on for these packet data interfaces is that jitter/phase-noise (from ALL the chips, etc.) is a cause, not an effect.  It transfers and along the way is creating ground-plane noise/bounce, which in turn creates threshold jitter for subsequent circuits--ultimately through to the DAC.

 

Please reread our paper (and the technically knowledgable can ignore our attempts to simplify/explain the more basic concepts) and look for the core of what we are explaining:

 https://cdn.shopify.com/s/files/1/0660/6121/files/UpTone-J.Swenson_EtherREGEN_white_paper.pdf?v=1583429386

 

 

This is pure fantasy in modern Ethernet, i.e. specifications within the last 20 years. The stressed eye pattern, or stressed receiver test was specifically designed 20 years ago to prevent this exact problem. 

 

Very nice story you continue to tell.  It simply doesn't happen on a competent network.

 

For further reading:

[R1200CL]

@jabbr

https://en.wikipedia.org/wiki/Carl_Bergstrom

 

That man work concerns the flow of information through biological and social networks. We’re talking about another network 🤓

[jabbr]

18 minutes ago, R1200CL said:

@jabbr

https://en.wikipedia.org/wiki/Carl_Bergstrom

 

That man work concerns the flow of information through biological and social networks. We’re talking about another network 🤓

 

The only jitter of consequence are in the unsupported stories, or lack of research into potential problems that were considered and solved in the last century. The arguments are very shaky and unsupported, yes, that kind of jitter?

 

From the linked "whitepaper"

Quote

Q. What about fiber-optic interfaces? Don’t these block everything? A. In the case of a pure optical input (zero metal connection), this does block leakage current, but it does not block phase-noise affects. The optical connection is like any other isolator: jitter on the input is transmitted down the fiber and shows up at the receiver. If the receiver reclocks the data with a local clock, you still have the effects of the ground plane-noise from the data causing threshold changes on the reclocking circuit, thus overlaying on top of the local clock.

 

This is exactly what the stressed receiver test looks for. The transmitter "injects" jitter into the signal, and the receiver need to be immune to a reasonable degree. You can't have significant ground plane bounce and keep a tight eye pattern. The ground plane literally is the bottom of the eye.

[Miska]

On 10/21/2020 at 3:47 AM, R1200CL said:

Buffers as I understand it, also have jitter, in and out, and amount of jitter may depending one their size.
But I think jitter in buffers is very low. So whenever data moves, there will exist digital jitter I suppose. 

 

Jitter that matters from audio point of view only exists only in the D/A conversion clock that is created by the DAC. Everything else in a properly made audio system is "timeless", meaning that DAC owns the clock and not someone else. This is not the case for all protocols, AirPlay being one example.

 

Size of a buffer defines how much jitter it can suppress. A one second buffer can eliminate up to about +-500 ms of jitter.

 

[ASRMichael]

9 hours ago, Miska said:

 

Jitter that matters from audio point of view only exists only in the D/A conversion clock that is created by the DAC. Everything else in a properly made audio system is "timeless", meaning that DAC owns the clock and not someone else. This is not the case for all protocols, AirPlay being one example.

 

Size of a buffer defines how much jitter it can suppress. A one second buffer can eliminate up to about +-500 ms of jitter.

 

Are you saying the only clock that matters is the DAC? 

[John Dyson]

16 hours ago, Superdad said:

What seems to be missed in most of these discussions is that what is going on for these packet data interfaces is that jitter/phase-noise (from ALL the chips, etc.) is a cause, not an effect.  It transfers and along the way is creating ground-plane noise/bounce, which in turn creates threshold jitter for subsequent circuits--ultimately through to the DAC.

 

Please reread our paper (and the technically knowledgable can ignore our attempts to simplify/explain the more basic concepts) and look for the core of what we are explaining:

 https://cdn.shopify.com/s/files/1/0660/6121/files/UpTone-J.Swenson_EtherREGEN_white_paper.pdf?v=1583429386

 

I agree -- I try to mention ground problems as being the 'ghost' that makes people think that the jitter is from some other strange, metaphysical effect.   There might be some kind of metaphysics going on, but I have found any so far :-).

 

John

 

[PeterSt]

2 hours ago, ASRMichael said:

A one second buffer can eliminate up to about +-500 ms of jitter.

 

It is not about that anyway (because upstream jitter won't end up as jitter 1:1 (see my previous post)), but *if* it would matter it is not about how many ms as such can be eliminated, but merely about how many ps (or better, fs) can be eliminated by a buffer.

 

Next up is how much jitter the buffer (circuitry) adds ...

[PeterSt]

3 minutes ago, John Dyson said:

but I have found any so far :-).

 

John, really ?

[John Dyson]

6 minutes ago, PeterSt said:

 

It is not about that anyway (because upstream jitter won't end up as jitter 1:1 (see my previous post), but *if* it would matter it is not about how many ms as such can be eliminated, but merely about how many ps (or better, fs) can be eliminated by a buffer.

 

Next up is how much jitter the buffer (circuitry) adds ...

If you do competent, good RF grounding & layout, instead of an ad-hoc layout that reminds of old audio equipment, the resulting jitter will be the same as the clock using to resynch the digital data.   There is an original A/D jitter whose effects cannot be removed, and will be contained in the DATA and not affected by subsequent digital clocks.  This assumes that the data isn't on the edge of the clock, which would be bad, out-of-tolerance design.     Of course, if the buffer is more than one, and the purpose is for rate conversion, then all bets are off if the 'jitter' (not the right word, really -- buffer underrun or overrun) is too great.

 

ADD-ON:  at the very end, the final amount of jitter is the final clock (assuming competent layout), plus the effects of the A/D sampling jitter at beginning of the chain.

 

John

 

[PeterSt]

3 minutes ago, John Dyson said:

If you do competent, good RF grounding & layout, instead of an ad-hoc layout that reminds of old audio equipment, the resulting jitter will be the same as the clock using to resynch the digital data.

 

Added jitter, John. Added jitter.

Of course you could could try to make some 100% direct A/D behind a (last) clock, but maybe it does not exist without whatever chips and added jitter.

But it wasn't about that ... it was about a buffer eliminating jitter. Thus show me buffer circuitry that plainly can't add jitter. Mind you, 100fs adds to 1ps of jitter just the same (and probably in a nasty way on top of that).

 

More originally (OP) it was about something else. And - just saying - if people keep on claiming that e.g. buffers would eliminate what upstream electronics impede, then indeed whatever is upstream shouldn't make a difference to the sound the DAC creates.

But it does ...

 

And btw, any "then your electronics or designs are not right / decent" ... yeah, we know that by now and are fed up with that. Thus:

All what's done upstream in the digital domain(s) and what does change the sound which (mind you !) can only be dedicated to jitter in the very far way downstream D/A process, has to be appointed to some source. And I say it is not jitter. I very explicitly say that. But it implies jitter right in front of the D/A at least (and mind you, that "in front" is usually a lot closer than where that clock resides (for example: an FPGA can be behind the clock-source; well, happy jitters with that).

 

Peter

[Miska]

3 hours ago, ASRMichael said:

Are you saying the only clock that matters is the DAC? 

 

Essentially yes... If you use asynchronous USB this is the case. Or something like a DAC with built-in NAA having internal I2S bus.

 

If you use S/PDIF or AES/EBU, then it is combination of the SPDIF/AES transmitter and DAC because in this case master clock is at the transmitter side and DAC needs to reconstruct it's master clock from this using a PLL (which vary in quality).

[Miska]

1 hour ago, PeterSt said:

It is not about that anyway (because upstream jitter won't end up as jitter 1:1 (see my previous post)), but *if* it would matter it is not about how many ms as such can be eliminated, but merely about how many ps (or better, fs) can be eliminated by a buffer.

 

Of course any ps or fs being much less than ms are gone much easier than large variations, such as random pauses of several ms in data transmission.

 

Just remember that none of these transmission methods, being network or USB don't send or clock any individual samples. They are packet based transmissions, sending larger blocks of data at once.

 

1 hour ago, PeterSt said:

Next up is how much jitter the buffer (circuitry) adds ...

 

It cannot add any, because it doesn't have any clock of it's own, it is slave.

 

[jabbr]

3 hours ago, ASRMichael said:

Are you saying the only clock that matters is the DAC? 

The global enterprise network market approaches $100 Billion yearly. All these devices have femtosecond range clocks. Good clocks in network devices are a given. PCs themselves are Getting there — the reason PCIe-4 has been rolled out slowly has to do with the difficulty reliably meeting the timing standards (tight eye patterns). It’s not that network clocks don’t matter, it’s just that network devices are already designed to high standards — when you talk about the horsepower of a Corvette, you aren’t measuring it against an actual pack of horses — we are beyond that.

[PeterSt]

11 minutes ago, Miska said:

It cannot add any, because it doesn't have any clock of it's own, it is slave.

 

??

 

[PeterSt]

8 minutes ago, jabbr said:

when you talk about the horsepower of a Corvette, you aren’t measuring it against an actual pack of horses — we are beyond that.

 

 

2CV ...