Jump to content
IGNORED

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


Recommended Posts

1 hour ago, Superdad said:

Pardon me gents, but any further discussion of Ethernet cables will result in my creating a new topic and transferring all such posts over there.  (I am sure there is an existing Ethernet cable thread somewhere, but my forum moderation capability is limited to moving posts to other topics within the UpTone sponsored area.)

Thanks! 

Sorry I sorta’ started this off-topic thread within a thread.  But I felt at the time, and still feel, the importance in all connections in/out of any switch in eventual sound quality.  Please fork this off with the other Ethernet cable bits if you wish. 

 

The Shunyata’s actually focus is on reducing transmission and phase distortion, including high frequency noise distortion.  

 

While awaiting the EtherREGEN, and now the Shunyata cables, I’ve had recourse to plug a Transparent TPM into my system wall plug 

 

https://www.transparentcable.com/collections/power-add-on-surge-protection/products/plug-in-network-protector 

 

connecting the outbound cable from my Cisco 2960 to this device and sending the cleaned-up signal on its way to my dCS gear. It has reduced noise from the upstream path. I’ve no idea if I’d perceive any benefit in using it once I have the Shunyata’s in place. 

 

Steve Schaffer

Grimm MU1 / dCS Vivaldi Upsampler - APEX DAC - Clock / Spectral DMC-30SV preamp / Spectral Anniversary monoblocks / Wilson Audio Alexia V /  Wilson Lōkē subs / Shunyata Everest / Shunyata Omega interconnects, power cables, Ethernet / Shunyata Altaira / Uptone EtherREGEN switch / Cybershaft OP21A-D / Uptone JS2 LPS / HRS racks - Vortex footers - damping plates

Link to comment
3 hours ago, stevebythebay said:

Sorry I sorta’ started this off-topic thread within a thread.  But I felt at the time, and still feel, the importance in all connections in/out of any switch in eventual sound quality.  Please fork this off with the other Ethernet cable bits if you wish. 

 

The Shunyata’s actually focus is on reducing transmission and phase distortion, including high frequency noise distortion.  

 

While awaiting the EtherREGEN, and now the Shunyata cables, I’ve had recourse to plug a Transparent TPM into my system wall plug 

 

https://www.transparentcable.com/collections/power-add-on-surge-protection/products/plug-in-network-protector 

 

connecting the outbound cable from my Cisco 2960 to this device and sending the cleaned-up signal on its way to my dCS gear. It has reduced noise from the upstream path. I’ve no idea if I’d perceive any benefit in using it once I have the Shunyata’s in place. 

 


You really need to be patient, and purchase the EtherRegen 😀

(Or even two)

 

Link to comment
9 minutes ago, mikicasellas said:

Tell her you won it over for the time you waited for it...."It was free Honey, FREEEEE"

 

Normally I beta test “everything” so this will also work :) :) :) 

Everybody wants my feedback lalalala 

#futureFi-is-peace-with-your-wife-Fi 

 

PS: I think the development time is adequate to the attention of detail and very transparent due to the excellent communication. 

 

Link to comment
2 hours ago, R1200CL said:


You really need to be patient, and purchase the EtherRegen 😀

(Or even two)

 

Have been and will continue to be patient. My experiences with a number of switches, including my current Cisco, have shown that with both my use of the Transparent device and recent experience with Shunyata Ethernet cables, these switches are clearly producing noise.  So, I fully expect a degree of benefit from the EtherREGEN. 

Steve Schaffer

Grimm MU1 / dCS Vivaldi Upsampler - APEX DAC - Clock / Spectral DMC-30SV preamp / Spectral Anniversary monoblocks / Wilson Audio Alexia V /  Wilson Lōkē subs / Shunyata Everest / Shunyata Omega interconnects, power cables, Ethernet / Shunyata Altaira / Uptone EtherREGEN switch / Cybershaft OP21A-D / Uptone JS2 LPS / HRS racks - Vortex footers - damping plates

Link to comment

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:

EtherREGEN.thumb.jpg.d34b9a5ce4f179f7a73b184a13d97485.jpg

 

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. 

Industry disclosure:
https://chicagohifi.com

Dealer for: Taiko Audio, Conrad Johnson, Audio Mirror, and Sean Jacobs

Link to comment

I would point the 100b at the music server, and point the 1gb (copper and optical) ports at every thing else. The point of the moat is to separate the “player” from the rest of the network.

 

I plan for the etherRegen to be the cleanup for my network, with the most isolation, and final reclocking for the port going directly to the player.

 

I use my NAS as a Roon server, and my Streamer/DAC for an endpoint. (No USB)

[Home Digital] MSB Premier DAC > Modright LS300 > Atma-Sphere "Class D" Monoblocks > Daedalus Audio Muse Studio Speakers

[Home Analog] Technics SL-1200G > Boulder 508 (Benz Glider SL)

[Office] Laptop > Kitsune R2R lvl3 > Violectric V281 > Meze Liric / Meze Elite

[Travel] Laptop/iPad -> Focal Bathys

Link to comment
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.

Industry disclosure:
https://chicagohifi.com

Dealer for: Taiko Audio, Conrad Johnson, Audio Mirror, and Sean Jacobs

Link to comment
1 hour 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:

EtherREGEN.thumb.jpg.d34b9a5ce4f179f7a73b184a13d97485.jpg

 

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. 

 

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

Link to comment
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. 

Industry disclosure:
https://chicagohifi.com

Dealer for: Taiko Audio, Conrad Johnson, Audio Mirror, and Sean Jacobs

Link to comment
3 hours ago, Nenon said:

 

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. 

 

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.

 

That said, another place I've found 100Mbps to be limiting is during system upgrades, especially if it involves a full OS upgrade of the DAC-attached endpoint/server.

 

Presumably, if you keep the NAS and the music server on the same side of the moat, while you don't get isolation, I'm guessing you still get reclocking?

 

Good question.

Link to comment
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:

EtherREGEN.thumb.jpg.d34b9a5ce4f179f7a73b184a13d97485.jpg

 

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? :)

 

 

 

 

 

Industry disclosure:
https://chicagohifi.com

Dealer for: Taiko Audio, Conrad Johnson, Audio Mirror, and Sean Jacobs

Link to comment
1 hour ago, Nenon said:

 

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. 

 

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? :)

 

 

 

 

 

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.

Link to comment

Maybe a bit OT, but somehow still relevant IMO if the ability of using a device is asked for.  

 

What SQ can be gained in reality by playing those extremely big files (and on ram) compared to more normal sized hi-res? The extra storage, transference, re-clocking, buffering, conversion, more clocking, more transfer and calculation of merely more zeros. This extra transfer, clocking and processing of zeros takes place multiple times in a digital streaming audio chain before the final Digital -> Analogue conversion.

 

The amount of small details that can be recorded and proceeded in a recording studio or live concert is reached and exceeded with 96 KHz 24 bit recordings. Left is the digital filtering that can be done in higher frequency if we make the files bigger by adding more zeros. If filtering in higher MHz would be better will say.

Link to comment
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. 

Industry disclosure:
https://chicagohifi.com

Dealer for: Taiko Audio, Conrad Johnson, Audio Mirror, and Sean Jacobs

Link to comment
1 hour ago, Nenon said:

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

 

+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. 

 

Indeed. 

 

Nenon, if you're interested, I looked into this interrupt behavior in the context of another workload: Squeezelite with large buffers on AL in ramroot. Different code, but similar behavior on the network. Here's the link: https://audiophilestyle.com/forums/topic/54933-audiolinux-and-nuc-troubleshooting-and-tuning/?do=findComment&comment=904234

 

 

Let's followup on that or the Euphony thread, as it's definitely OT here.

Link to comment

Hi,

 

I am not to familiar on the capabilities of the Etherregen as not done my research but can someone explain what would be the benefit of using this as apposed to a good quality Ethernet cable like the Shunyata Alpha with a built in filter module?

Link to comment
23 hours ago, Nenon said:

 

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. 

 

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

Link to comment
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.

Industry disclosure:
https://chicagohifi.com

Dealer for: Taiko Audio, Conrad Johnson, Audio Mirror, and Sean Jacobs

Link to comment
1 hour ago, Nay said:

Thanks for your pointless input 🤬🤬🤬

 

Even reading the first entry of this thread will answer your question. Most of us are carefully watching this thread as the etherRegen is being refined, and perhaps finalized, this go ‘round. From the last news, you have several months to read/digest this thread for fine points.

 

OP has specifically asked to exclude Ethernet cable talk from this thread. I would think if you wanted to limit your reading, the cable discussion had been in the last 4-5 pages, ending when asked by the OP.

[Home Digital] MSB Premier DAC > Modright LS300 > Atma-Sphere "Class D" Monoblocks > Daedalus Audio Muse Studio Speakers

[Home Analog] Technics SL-1200G > Boulder 508 (Benz Glider SL)

[Office] Laptop > Kitsune R2R lvl3 > Violectric V281 > Meze Liric / Meze Elite

[Travel] Laptop/iPad -> Focal Bathys

Link to comment
31 minutes ago, Bones13 said:

 

Even reading the first entry of this thread will answer your question. Most of us are carefully watching this thread as the etherRegen is being refined, and perhaps finalized, this go ‘round. From the last news, you have several months to read/digest this thread for fine points.

 

OP has specifically asked to exclude Ethernet cable talk from this thread. I would think if you wanted to limit your reading, the cable discussion had been in the last 4-5 pages, ending when asked by the OP.

Thank you,

 

I did not realise until i have read further back regarding the discussion of Ethernet cables is a no go.

 

The Etherregen looks the way to go so hoping to see it available soon?

Link to comment

@JohnSwenson a question regarding the metallcase around the LAN port on the B-side how is that connected to other parts of the etherREGEN? Is there a connection to other metallcases (RJ45 A-side) and to the groundconnection or is it floating compared to them for example?

My intrest in this is rather hypothetical, if I were to use a sheilded ethernetcable (with screen connected to the plug) from the B-side to streamer would this make a connection from upstream on A-side cables to the b-side streamer cable "if" they have the screens connected in the plugs on both sides A and B on the etherREGEN?

 

UpTone EtherREGEN pre-production1.jpg

Main system
TAD D1000mk2, TAD M2500mk2, TAD CE-1, Ansuz Mainz 8 C2, Ansuz Darkz D-TC, 
Qobuz Studio -> Roon ROCK on NUC -> Uptone etherREGEN -> dCS Network Bridge -> AES/EBU -> DAC
HD Plex 200W PSU (4 rail for ISP fiber, router, etherREGEN and NUC)
 
Second system
Qobuz Studio -> Devialet Silver Phantom, Devialet Tree
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...