EtherREGEN: The long development thread. [Some Gen2 dev. pics and update starting on page 92.]

[Nenon]

Was the final (or estimated) price determined yet? Sorry if I missed a post... kind of a long thread. Thank you. 

[Nenon]

On 7/14/2019 at 12:04 PM, tboooe said:

Streaming high res uses way less than 100mbps so there is no need to aggregate.  In my system, even DSD512 uses only about 50mbps.

 

Don't forget that there are other use cases.

In my system (Euphony/Stylus), when I hit the play button, the track gets downloaded from my NAS to my music server, loaded completely in RAM, and played from RAM. It would take close to 3 minutes to download a 2GB DSD512 track over 100Mbps connection. Luckily my files are not that big at the moment, but if they were, I would have to wait 3 minutes between tracks...

I read the technical explanation why the port is limited to 100Mbps, but it is kind of a bummer.

 

[Nenon]

One server solution. Local files are stored on a NAS. The server loads the entire track in RAM before playing. 

Apparently to get the most out of the EtherREGEN, we need the signal to cross the moat. That unfortunately limits one side to 100 Mbps. Some larger DSD files would take quite a long time to load in RAM over a 100 Mbps connection. 

I am thinking what would be the best way to implement the EtherREGEN in such case? 

 

So far, this is the best idea I have come up with:

 

Streaming Tidal / Qobuz would go across the moat, that would be quite beneficial. 

Loading tracks from the NAS to the RAM on the music server would have to be done over 1Gbps connection. No crossing the moat, so not using the most benefits of the switch. But adding an opticalModule would help isolating the noise from the NAS and would also do some reclocking (not as good as EtherREGEN if I understand correctly, but at least better than nothing). The JCAT NIC also has a good clock, so perhaps that would be an acceptable compromise for this use case. 

 

@Superdad @JohnSwenson - do you have any better suggestions? 

 

Thank you. 

[Nenon]

2 minutes ago, Bones13 said:

 

I would point the 100b at the music server, and point the 1gb (copper and optical) ports at every thing else.

 

 

And I would have to wait a minute after every track until the next one loads in RAM over the 100 Mbps connection. 

If it was not clear from my post - I am trying to avoid the traffic from the NAS to my server to go over 100 Mbps connection.

[Nenon]

22 minutes ago, GryphonGuy said:

 

As others have said, assign your Music Server to the 100Mbit/sec output port because even the highest definition stereo music only needs a couple of Mbits/sec. 4K video, the current most demanding service only needs around 25Mbit/sec.

 

The way you have your design you will create a bottleneck in your network, exactly what you say you want to avoid.

 

In fact, I will be running fibre from my main switch to the EtherREGEN (stereo is about 25 metres from switch on another floor) then using copper from the 100Mbit/sec port on the EtherREGEN to the UltraRendu and then onto the Chord DAVE. If my understanding is correct, this was one of the design intentions.

 

Regards

GG

 

I guess I need to explain how pre-loading in RAM is different than streaming.

 

Not all the DSD files are that big, but some are. Let's take an extreme case. It takes over 80 seconds to transfer a 1GB file over 100 Mbps connection. So let's say hypothetically that I have an album with 10 DSD tracks of that size. Here is what happens:

- I click play.

- I wait 80+ seconds for the file to load in RAM. 

- The track start playing. The music stops at the end of the track.

- The second track starts loading.

- I wait 80+ seconds for the second track to load.

- Repeat the same process above for the rest of the tracks... 

 

1 GB file is a very extreme case. Most of my files are much smaller. Let's say an average file is 150 MB. That is still a 12+ seconds gap between tracks. That would be quite an unpleasant experience over 100 Mbps connection. If we bump it up to 1 Gbps connection the gap would be just a little over a second on an average file size. 

[Nenon]

1 hour ago, austinpop said:

Interesting scenario. I certainly have tracks that exceed 1GB in size. Are you referring to Stylus on Euphony OS - i.e. "Buffer before playing = 100%"?

 

If so, while it is definitely true you'll incur the pre-load delay for the first track, it should not be an issue for subsequent tracks. Especially if you've also set the "Use Cache"  flag. In that case, all tracks that are added to the Queue start getting loaded into the local filesystem cache, from where they are then loaded to RAM for playback. While you'll wait for the first track to transfer, the remaining tracks will transfer while you're listening. Additionally, the gapless playback algorithm in Stylus preloads the next track (from cache), so you really don't have to incur the delays on every track.

 

It was an exaggerated example, mainly for illustration purposes to the responses saying that 100Mbps is more than enough. Yes, I am using Euphony at the moment, and the example I gave is not exactly how Euphony works.

 

This is getting a little offtopic, so if @Superdad decides to delete, please go ahead. 

 

The gapless playback algorithm in Euphony definitely helps with slower bandwidth. But I have also noticed that those Euphony background processes decrease the sound quality in my system, even with the powerful i9-9900K CPU. They consume very little of the CPU, but it is still an audible decrease in sound. In some cases when I see more than a couple of cores using over 1% CPU, I would restart the Euphony app (which kills most background processes) and all of a sudden the magic comes back a few seconds later. And the sound becomes much better. I have done this a number of times and the effect is always the same. 

So while the gapless playback algorithm does what the name says - it works in the background to cache all tracks from the playlist to my Euphony cache drive (i.e. a partition on my Optane card), it also decreases the sound quality. Obviously the longer it runs, the worse the effects are... or I should say the longer the negative impact of this background process is sustained for.

In my example of 10 large DSD tracks, once you click play, you would wait 80+ seconds for the first track to start playing, and then in the next 12-15 minutes a background process would be downloading the rest of the album to my Optane card. So somewhere around the end of track #2 or #3 the sound quality would become optimal. Or at least that's what I would experience in my system. I would like to reduce that negative impact 10 times by using 1 Gbps instead of 100 Mbps. 

 

But here is a more simple example - Let's say I want to browse my library and jump from one album to another. That would be a painful experience with "Buffer before playing = 100%" enabled for the tracks that are not yet cached. I may have to wait 80+ seconds for every track I click on. Or maybe not 80+ but you get the point. I have used an industrial grade 100 Mbps fiber media convertor which sounded great (especially after I upgraded its power supply caps and fed by a good LPS), and have experienced that with Euphony. If I added a bunch of new albums to my library and wanted to quickly scan through them, I had to either bypass the 100 Mbps media convertor or disable the "Buffer before playing = 100%" option. In some cases I ended up switching from Stylus to Roon. Roon has no issues with 100 Mbps bandwidth but it just does not as good. 

 

Hopefully that adds a little more clarity as to why I asked my original question. 

5 hours ago, Nenon said:

One server solution. Local files are stored on a NAS. The server loads the entire track in RAM before playing. 

Apparently to get the most out of the EtherREGEN, we need the signal to cross the moat. That unfortunately limits one side to 100 Mbps. Some larger DSD files would take quite a long time to load in RAM over a 100 Mbps connection. 

I am thinking what would be the best way to implement the EtherREGEN in such case? 

 

So far, this is the best idea I have come up with:

 

Streaming Tidal / Qobuz would go across the moat, that would be quite beneficial. 

Loading tracks from the NAS to the RAM on the music server would have to be done over 1Gbps connection. No crossing the moat, so not using the most benefits of the switch. But adding an opticalModule would help isolating the noise from the NAS and would also do some reclocking (not as good as EtherREGEN if I understand correctly, but at least better than nothing). The JCAT NIC also has a good clock, so perhaps that would be an acceptable compromise for this use case. 

 

@Superdad @JohnSwenson - do you have any better suggestions? 

 

Thank you. 

 

I can think of a few different ways of doing that but wanted to hear from the experts who designed the EtherREGEN if they have a prefered solution for that scenario. It's clear that crossing the moat gives best results and that the best thing to do is not to connect anything on the side where the server resides. But given the @JohnSwenson designed both, the EtherREGEN and the opticalModule, he might have some inside knowledge of what might work best. 

 

Regardless of the outcome, I am still getting an EtherREGEN as soon as I could get my hands on one /we are really hoping for this October(EtherREGEN)Fest :)/. . And trying in my system would be the best way to find out what works best for me. If that's the answer, I accept it, but it does not hurt asking, right?

 

 

 

 

 

[Nenon]

7 hours ago, JohnSwenson said:

One thing to consider is that your current situation of sending music through the Ethernet while playing significantly degrades sound may in fact go away when using an EtherREGEN, that is in fact its primary purpose, to get rid of anything coming over the network that will degrade sound.  It seems like your assumption is that the degradation is coming from the renderer itself having to deal with the data rather than from what is coming over the connection itself. It's hard to tell exactly which it is.

 

The EtherREGEN may clean up the external degradation so much that having music data coming over the wire wile it is being played does not cause any degradation. Or there still might be some effect from the renderer's  electronics itself. That's going to be hard to tell until you try it. 

 

Unfortunately there is no way anyone can tell you exactly how it is going to turn out in any situation, the fully functional EtherREGEN simply does not exist at this point in time. Even if I had all the equipment you have I couldn't test it since I don't have a fully functional board at this point. I'm not trying hide things or be difficult, It just cannot be done right now. There is no way I can tell yow what configuration is going to sound best. There is just no way I can do that right now. Any attempt at making a pure guess would be a disservice to the community.

 

It seems to me that the best way to deal with this, is wait until you have an EtherREGEN, then try it in the different modes, see if prebuffering everything before playing is in fact better than data coming over while playing, THEN we have some information to start coming up with scenarios for testing to find out what ultimately is best for you.

 

John S.

Thank you, John. Will patiently wait and try when the time comes.

 

8 minutes ago, lmitche said:

My assumption is the interrupt processing on the receiving PC with a streaming NIC port creates noise on it's own given the  necessary context switch, and that is going to be a constant, EtherRegen or not. I guess one could try larger frames to see if that changes things, but that is another ball of wax. No doubt ram buffering eliminates at least a part (up to half)  of this interrupt processing noise but part of it will always be there.

+1. That's exactly what I was thinking too. I have witnessed similar sound quality degradation simply from scanning my local library, even with the network cable unplugged.  So I agree that it's more likely the result of the interrupt processing. 

 

Let's move on. We'll post the outcome of our tests in another thread when we have an EtherREGEN in our hands. 

[Nenon]

4 hours ago, GryphonGuy said:

 

Maybe, just maybe, you will no longer need to play from RAM given that the EtherREGEN promises to clean-up (de-noise?) the network signal. Or at least you could lower the percentage from 100% to some other less hiatus-inducing setting without destroying your currently enjoyable level of perceived sonic purity.

 

Regards

GG

 

Based on my OS tweaking experience so far, I highly doubt it. But we would not know for sure until we get one.

[Nenon]

I know everyone following this thread is sitting by the keyboard now and wondering "Should I ask? Or should I wait? Should I ask? Or maybe Alex will say it any moment? No, I should probably ask, maybe he forgot! No, he can't forget, I probably should not bother him...Should I ask anyway?" .

So let me pull the trigger:

 

@Superdad Alex - how far are you from announcing an official launch date? 

From following this thread, it seems like the testing is going really well, the PCB manufacturer has all the parts and needs 3 weeks, the chassis were ordered a while ago, and you were working on the website and product documentation. We must be close to getting a date, right? 🤞

[Nenon]

Awesome! Thanks for the update Alex. This is top notch communication as always!

 

3 minutes ago, Superdad said:

So forgive me if I step back for a week while I try to focus on getting everything else together.

Our pleasure. Looking forward to the launch email.

[Nenon]

9 hours ago, Superdad said:

Even stereo DSD512 uses only about half that bandwidth.  Maybe if you were attempting 8 channels at very high rates might you run into an issue.  

 

Those of us who use Euphony and cache the track before playing would have to wait hefty 2+ minutes before a DSD512 track is downloaded at 100 Mbps. But we would still buy an ER. I keep trying to make that point, but it keeps getting ignored with comments about streaming. Streaming and caching are two completely different strategies, and so far caching has sounded best to my ears (unless it's analog). 

[Nenon]

5 hours ago, R1200CL said:

Blue Jeans is just fine. You may use minimum length of one meter. But this is not a requirement. 
Don’t use a cable with metal plugs if the plugs are connected. 
The Audioquest Vodka will do, but is totally overpriced. 
 

If you must use something extremely good, this one has implemented John’s theory how to build a Faraday Cage into a cable. 
Nicknamed JSSG (John Swenson Shielding Guidelines). And later extended into JSSG360 by another member here at the forum. 
 

This technology has been very successful on DC cables. 

 

I think it's a mistake to apply knowledge gathered from other products to the EtherREGEN. For example, the idea not to connect the metal plugs comes from tests where noisy devices were connected to your DAC/Streamer. The common ground would transfer noise from the noisy device to your DAC, which would result in sound quality degradation. 

I would consider the properly isolated output of the EtherREGEN as a very clean source with as little noise as possible. I would also take every care to preserve that signal as clean as possible. What works and what makes a difference is yet to be determined. We should consider every possible option to preserve the clean signal. 

[Nenon]

Good job on the manual. PM with some comments sent! 

[Nenon]

2 hours ago, JohnSwenson said:

The whole purpose of the EtherREGEN is to greatly reduce effects coming from the upstream system. So assuming you have the B port attached to the audio endpoint, don't worry about what is connected to the A side ports. Cables, switches, servers etc should all have very little impact (if any) on the sound quality. So don't worry about them.

 

Yes the cable from the B port to the endpoint might matter, but again don't worry about it. I'm using a dirt cheap no name 5 foot CAT5e cable between the EtherREGEN and the streamer and the improvement is phenomenal. I'm so enthralled with what I'm hearing now I'm not worrying about CAT7 or CAT8 etc.

 

Just get it IN the system however you can and LISTEN to music. After doing that for a couple months then maybe start looking into tweaks. You are going to find out that everything you knew about what makes a digital system better is now all turned around. Make sure you spend some significant time listening with just the EtherREGEN as the only change, and then if you still desire to tweak, throw out any previous concepts about what matters and slowly start trying things again.

 

John S.

 

Nice leak :). I guess @JohnSwenson is not considered a 'beta tester' and there is no ban from @Superdad to share his experience :). 

Well, that make those of us who placed an order even more excited and impatient now 

 

[Nenon]

Wait until the word spreads out to the home theatre enthusiasts... the market there is much bigger!