So I've had an EtherRegen in rack for 2 weeks...

[firedog]

9 hours ago, RickyV said:

FYI.

 

He proved his technical incompetence when talking about MQA, and used his lack of understanding to wrongly explain what he was hearing. So his subjective evaluations  are clearly totally based on his expectation bias. I wouldn't put stock in a thing he says, about this, or any other product. 

[jabbr]

3 hours ago, The Computer Audiophile said:

Doesn't a buffer just mean jitter in - jitter out, but delayed?

Lets take an idealized situation with Ethernet in DAC. The Ethernet packets of bits arrive (Ethernet clock) and are placed into a TCP buffer (cpu clock) which is itself fed into a FIFO buffer. The DAC reads out each bit in turn (DAC clock). Each clock is a different frequency. 

[The Computer Audiophile]

1 hour ago, jabbr said:

Lets take an idealized situation with Ethernet in DAC. The Ethernet packets of bits arrive (Ethernet clock) and are placed into a TCP buffer (cpu clock) which is itself fed into a FIFO buffer. The DAC reads out each bit in turn (DAC clock). Each clock is a different frequency. 

Does changing clocks (Eth > CPU > DAC) always mean changing jitter?

[jabbr]

8 minutes ago, The Computer Audiophile said:

Does changing clocks (Eth > CPU > DAC) always mean changing jitter?

When you clock the bits into a memory buffer you lose the jitter from the incoming clock, and when you clock the bits out of the buffer you gain the jitter from the outgoing clock. 
 

The jitter is not additive when the FIFO is properly implemented.  The recent (since 2002) Ethernet specs require that. That way you can send a packet around the world and it arrives perfectly. 

[The Computer Audiophile]

14 minutes ago, jabbr said:

When you clock the bits into a memory buffer you lose the jitter from the incoming clock, and when you clock the bits out of the buffer you gain the jitter from the outgoing clock. 
 

The jitter is not additive when the FIFO is properly implemented.  The recent (since 2002) Ethernet specs require that. That way you can send a packet around the world and it arrives perfectly. 

Yes of course packets arrive perfect, but I wasn’t absolutely positive jitter was made a non-issue at each stage. 

[jabbr]

53 minutes ago, The Computer Audiophile said:

Yes of course packets arrive perfect, but I wasn’t absolutely positive jitter was made a non-issue at each stage. 

Jitter isn’t a non-issue, rather, when properly implemented, the jitter from the outgoing clock predominates to the point that the incoming jitter contribution is immeasurable, or at least lower than an arbitrary number. By lengthening the FIFO buffer size, or even placing additional FIFO stages, the isolation between incoming and outgoing jitter increases. 

Define “non-issue” and you can design a buffer to make it so,

[plissken]

Here is a Cisco document on Buffer Misses

https://www.cisco.com/c/en/us/support/docs/interfaces-modules/channel-interface-processors/14620-41.html

[Jud]

18 hours ago, plissken said:

 

Can we agree on this: Jitter is a variance in what would be the otherwise optimal timing of a signal? Can we also agree that there is always going to be some jitter on all signals if we get a powerful enough measurement device on it?

 

Sure. The question is always going to be whether the jitter is at a level that causes concern, whether by virtue of a certain amount of measured distortion or audible noise.

 

Please listen to these two files and tell me what you hear. Note the quality isn't the best because they were made simply by holding an iPhone in front of speakers more than 3 years ago.

 

1A.m4a A1.m4a

[plissken]

36 minutes ago, Jud said:

 

Sure. The question is always going to be whether the jitter is at a level that causes concern, whether by virtue of a certain amount of measured distortion or audible noise.

 

Ok so this will bring me to a point I want to make:

If we can agree on the fact that jitter is variance outside of perfect/optimal timing, and I start play back, and cause the largest possible jitter, and that is pulling the Ethernet cable, and the music still plays. Trust me you pull an Ethernet cable mid transfer you've created an incredible amount of jitter.

 

What does any jitter on the Ethernet input have to do with any jitter a USB / AES-EBU / S-PDif may introduce?

[jabbr]

55 minutes ago, Jud said:

 

Sure. The question is always going to be whether the jitter is at a level that causes concern, whether by virtue of a certain amount of measured distortion or audible noise.

 

Please listen to these two files and tell me what you hear. Note the quality isn't the best because they were made simply by holding an iPhone in front of speakers more than 3 years ago.

 

1A.m4a 3.31 MB · 5 downloads A1.m4a 3.26 MB · 1 download

 

If I try to play on my iPhone I initially thought I heard  this:

https://youtu.be/6ukmjBSQY-c

but then realized its more like this:

https://youtu.be/B9z87viDmOo

 

When jitter is added, its much more clearly:

https://youtu.be/Bk7RVw3I8eg

 

 

[jabbr]

18 minutes ago, plissken said:

 

What does any jitter on the Ethernet input have to do with any jitter a USB / AES-EBU / S-PDif may introduce?

 

That should be a measurement made with access to a particular brand of Ethernet equipment and USB transmission equipment.

 

For example you can measure the USB jitter (could be eye pattern as summary but also could be full phase offset plot). 

 

You could, for example, use a Cisco ethernet switch, input to microRendu and then measure USB output. You could add an ISORegen and then remeasure output. You could substitute EtherRegen for Cisco (for example) and then remeasure output.

 

Aside from theory these things are measured every single day my equipment manuf for compliance testing (see the microsemi article I posted in the General Forum).

[pkane2001]

1 hour ago, Jud said:

 

Sure. The question is always going to be whether the jitter is at a level that causes concern, whether by virtue of a certain amount of measured distortion or audible noise.

 

Please listen to these two files and tell me what you hear. Note the quality isn't the best because they were made simply by holding an iPhone in front of speakers more than 3 years ago.

 

1A.m4a 3.31 MB · 6 downloads A1.m4a 3.26 MB · 3 downloads

 

Here's the way I go about answering such questions for myself. Add jitter in any quantity to a high quality recording, play it back on your best system, speakers or headphones, and see if you can hear the difference. DISTORT app does this with a simple set of configuration settings. Pick the type of jitter (or combination of various types) that you want, apply it to your favorite music track, and just listen. Can you hear femto-second jitter? I can't. 

 

[jabbr]

6 minutes ago, pkane2001 said:

 

Here's the way I go about answering such questions for myself. Add jitter in any quantity to a high quality recording, play it back on your best system, speakers or headphones, and see if you can hear the difference. DISTORT app does this with a simple set of configuration settings. Pick the type of jitter (or combination of various types) that you want, apply it to your favorite music track, and just listen. Can you hear femto-second jitter? I can't. 

 

 

Paul, very nice!

 

I just want to point out that we have no idea about how jitter on an Ethernet or USB input would affect a DAC or the output of a DAC, so no way to even speculate that it would result in the distortion you are applying to the audio!

 

Actual measurements of actual equipment are essential to settle the speculation.

[plissken]

18 minutes ago, jabbr said:

 

That should be a measurement made with access to a particular brand of Ethernet equipment and USB transmission equipment.

 

Or I could, using my example, feed an ADC over the wire audio, and repeatedly plug and unplug the Ethernet cable and see when people can tell when the cable was pulled.

 

I think you see my point.

[pkane2001]

42 minutes ago, jabbr said:

 

Paul, very nice!

 

I just want to point out that we have no idea about how jitter on an Ethernet or USB input would affect a DAC or the output of a DAC, so no way to even speculate that it would result in the distortion you are applying to the audio!

 

Actual measurements of actual equipment are essential to settle the speculation.

 

Of course, we don't know how each DAC and the receiver circuit will react to different amounts of jitter at the input, although that can also be measured with some really expensive equipment. But, the output of a DAC is really what counts in the end for us, audiophiles, doesn't it? Since there is equipment and software capable of measuring jitter at the output, something like DISTORT can help one decide just how much jitter and of what type can become an audible issue. 

[Jud]

1 hour ago, plissken said:

 

Ok so this will bring me to a point I want to make:

If we can agree on the fact that jitter is variance outside of perfect/optimal timing, and I start play back, and cause the largest possible jitter, and that is pulling the Ethernet cable, and the music still plays. Trust me you pull an Ethernet cable mid transfer you've created an incredible amount of jitter.

 

What does any jitter on the Ethernet input have to do with any jitter a USB / AES-EBU / S-PDif may introduce?

 

What did you hear when listening to those files?

[thyname]

8 minutes ago, Jud said:

 

What did you hear when listening to those files?

This whole thing had nothing to do with hearing or listening 😉😬

[mansr]

4 minutes ago, thyname said:

This whole thing had nothing to do with hearing or listening 😉😬

Right, it was all about tracking every forum plissken visits and accusing him of running some kind of hit squad.

[plissken]

28 minutes ago, Jud said:

 

What did you hear when listening to those files?

 

I haven't had a chance to listen.

[plissken]

14 minutes ago, mansr said:

Right, it was all about tracking every forum plissken visits and accusing him of running some kind of hit squad.

 

If I was the one starting threads all over that would be one thing. But these are threads already started by others.

[Confused]

18 hours ago, Jud said:

 

Sure. The question is always going to be whether the jitter is at a level that causes concern, whether by virtue of a certain amount of measured distortion or audible noise.

 

Please listen to these two files and tell me what you hear. Note the quality isn't the best because they were made simply by holding an iPhone in front of speakers more than 3 years ago.

 

1A.m4a 3.31 MB · 8 downloads A1.m4a 3.26 MB · 7 downloads

Out of curiosity, I had a listen to these two this morning.  Lets just say one sounded quite good considering it was recorded with an iPhone, the other did not.  The bad one sounded a bit like a reel to reel tape recorder that had seen better days and is in need of a service, lots of wow and flutter and electrical issues.  I assume something else was in play though?

[Jud]

4 hours ago, Confused said:

Out of curiosity, I had a listen to these two this morning.  Lets just say one sounded quite good considering it was recorded with an iPhone, the other did not.  The bad one sounded a bit like a reel to reel tape recorder that had seen better days and is in need of a service, lots of wow and flutter and electrical issues.  I assume something else was in play though?

 

Appreciate it. Want to give plissken time to have a listen because I think it may be relevant to some of what's been discussed here in his thread.

[davide256]

Continuing to like what I hear with EtherRegen using my normal setup. I play mostly 44.1/16 movie and musical soundtracks, a lot of these have what

I call "wall of sound" overtures that didn't resolve well on my system. I was blaming this on CD format limitations, usually gets better if I can find a 96/24 version. However ER allows these to resolve to where they are enjoyable vs a piece of music I tended to skip. A particular success was the HDTracks 44.1/24 download

of "The Hobbit" soundtrack. While I like the source material, for some reason most  of the content in LOTR 44.1 soundtracks sound obnoxious on my system;

last night was the first time I was able to enjoy listening to the recording without gritting my teeth (other than at what sounded like synthesized violins).

Improvements continue to depend on the harmonic complexity, simple instrument lines don't illicit any difference but complex groupings of voice or

french horn that without ER sounded off pitch/atonal now sound correct. Note that Euphony does buffer so that all listening was done with music

stored in RAM, shouldn't make a difference but I did purge song  RAM cache each time I switched the ER in and out.

 

Sound tracks used: The Hobbit, Avatar, Apollo 13, The Last Samurai, Saving Private Ryan, The Last of the Mohicans, Pirates of the Caribbean-COBP

 

Will do some sampling today using just the stock power supply for NUC instead of the JS-2, looks like next weekend to trial the i5 PC

 

[davide256]

On 2/14/2020 at 10:09 PM, jabbr said:

When you clock the bits into a memory buffer you lose the jitter from the incoming clock, and when you clock the bits out of the buffer you gain the jitter from the outgoing clock. 
 

The jitter is not additive when the FIFO is properly implemented.  The recent (since 2002) Ethernet specs require that. That way you can send a packet around the world and it arrives perfectly. 

MEF standards are unkind to small packet sizes for throughput so I suspect we really need to think of network jitter as an Nxsample phenomena. Kind of a stop and go signal

phenomena when it occurs as buffer exhausts and refills. Not really the same thing as clock issues feeding DAC...the signal never stops there but its timing is untrustworthy.

[jabbr]

2 hours ago, davide256 said:

MEF standards are unkind to small packet sizes for throughput so I suspect we really need to think of network jitter as an Nxsample phenomena. Kind of a stop and go signal

phenomena when it occurs as buffer exhausts and refills. Not really the same thing as clock issues feeding DAC...the signal never stops there but its timing is untrustworthy.

Not sure about MEF standards. Are those for cellular? The standards used in my system are IETF. Ethernet -> TCP/IP. 
 

The “jitter” related to clocks is in the wire/Ethernet, but there are higher level possibilities. You could always use another protocol like RTP or Ravenna but that’s another level complexity and probably not practical unless you could really demonstrate an issue with TCP. 
 

Though consider @plissken’s example of plucking the wire: at 10G you could essentially transmit the entire song during the silence in between songs, and so playback might only occur during network silence. That would be a software issue ala NAA/networkaudiod or DLNA etc. 

 

Before trying to develop a new protocol I would want to see some hard evidence that it would solve a real problem. Does the EtherRegen repack packets?