Problem with JCAT network card and etherREGEN

[DRVaudio]

I have not been able to achieve a stable setup with ROON on a PC (WIN10), a JCAT net card FEMTO connected to the A-side of an etherREGEN (other A-side connections are a Ubiquiti EDGErouter X, and a PC/WIIN10). The B-side of the ER is connected to a SoTM sMS200ultra (using the latest Eunhasu software), which is connected to an isoREGEN. The DAC is a DSD-only Lampizator with a super-amanero card. None of the ethernet cables are shielded and the ER is grounded and both the ER and IR are using their onw Uptone switching PSs. I am converting all of the audio to DSD-256 (the only other DSP is to balance my left and right speakers.

 

I am randomly losing my internet connection or skipping/stopping tracks in ROON. I am confident of my connecting cables and have optimized the Eunhasu, ROON, and WIN10 driver buffers. Additionally, I am running Cloudflare WARP.

 

When I replace the etherREGEN with a stock NETGEAR switch (GS108) the network connection is stable and ROON does not skip or stop track.

 

Currently the when the etherREGEN is in the setup it can be stable for many hours then go "crazy" until I replace it with the NETGEAR switch, which INSTANTLY reconnects the internet. When I switch back to the ER, it takes many minutes to re-establish a stable internet connection.

 

Any suggestion will be appreciated.

[One and a half]

I found that the ER needs to be on 'first', then power up everything else. If you hot swap Ethernet connections the stability of the ER results in what you describe. 

Then again, the PC where the files reside, is always on, the audio system is switched 'on demand' including the ER. 9 times out of 10, the ER works fine, the 1/10th, the ER is powered off and on again after a while, and normal comms restored.

 

IP address to the endpoint is DHCP, the PC has the JCAT Femto networked bridged, that MAC has its IP address assigned by the router permanently as the same address.

 

Roon communicates with the endpoint quite well, but it can't ride through network interruptions elegantly.

[DRVaudio]

So, I should:

1. Power off the the ER, the audio computer, and the sMS200ultra

2. reconnect the ethernet cables

3. Power on the ER, then

4. Power on the sMS200ultra and the audio computer

 

 

[JohnSwenson]

5 minutes ago, DRVaudio said:

So, I should:

1. Power off the the ER, the audio computer, and the sMS200ultra

2. reconnect the ethernet cables

3. Power on the ER, then

4. Power on the sMS200ultra and the audio computer

 

 

Are you running the conversion to DSD using HQP? HQP can have problems when the Ethernet port on the computer it is running on is at a different speed than the port on the endpoint. Since the B side port on the ER is fixed at 100Mbps,  this frequently does happen. One solution is to set the output port (I presume on the JCAT card) to 100Mbps.

 

The other issue that seems to crop up is DHCP lease renewals. There are actually two issues here: slow renewals and IP address changing. A lot of residential routers (where the DHCP server is usually located) have a problem that the DHCP server gets slower and slower the longer they have been powered up (it usually takes a month or two for this to show up, but most people leave their router on for months at a time). The ER with its isolation and 100Mbps speed can can take slightly longer than a regular gigabit switch to pass the renewal request to the router. IF the DHCP server is getting slow that just might be enough extra delay to prevent the renewal process from happening properly. A test for this is to power off and power on your router and see if that makes any difference.

 

The other possibility is DHCP lease renewals giving your endpoint a different address, this can wreak havoc with audio protocols. I used to have this problem on my system, I switched to a different router and poof, the problem went away. Usually the best way to deal with this is to set a reserved address for the endpoint. You need the MAC address of the endpoint and your DHCP server needs to let you do that. With this in place the endpoint will always get the same address.  Some DHCP servers also have a setting that says that once the server has given the device an address it will always use that same address. You don't assign the address, but the result is the same, it never changes.

 

It is hard to say which your problem might be.

 

John S.

[DRVaudio]

I used the "power-up" sequence the you suggested. It went very smoothly. Since that power-up, ROON as stopped about 6 times (every other track). Your "lease renewal" issue sound plausible. I recently purchased and installed a Ubiquiti EdgeRouter X, which I hope will let me reserve an address for the sMS200ultra. How do I convert a MAC to an IP address; or perhaps the EdgeRouter Dashboard will let me enter a MAC address directly? Is there a "Networking for Dummies" that I can purchase?

 

[DRVaudio]

Sorry, I forgot to note that I am not using HQP.

[JohnSwenson]

5 minutes ago, DRVaudio said:

I used the "power-up" sequence the you suggested. It went very smoothly. Since that power-up, ROON as stopped about 6 times (every other track). Your "lease renewal" issue sound plausible. I recently purchased and installed a Ubiquiti EdgeRouter X, which I hope will let me reserve an address for the sMS200ultra. How do I convert a MAC to an IP address; or perhaps the EdgeRouter Dashboard will let me enter a MAC address directly? Is there a "Networking for Dummies" that I can purchase?

 

Every network box has its own MAC address, these are unique across the whole world. When a device powers up it asks the DHCP server for an IP address, the server has a "pool" of address and assigns an unused one to the device. This address is not forever, it is a timed lease. Halfway through the "time" the device asks for a renewal, the server can either give it the same address or a different address. The pool usually does not cover the entire space, there are usually some leftover addresses for special things.

 

A reserved address tells the server to give a specific address to the device with a specific MAC. The best practice is to choose an address that is outside of the pool. You find that out by accessing the routers web page (the manufacturer has to tell you how to do THAT), go tho the DHCP server section and it should tell you what the current pool is. Choose an address outside of that pool.

 

Most residential routers run on an address space with 256 possible addresses, the pool might have 200 of those. For example a common address setup would like something like 192.168.1.xxx where xxx is 0-255.  The router itself is usually 1 (so 192.168.1.1), some pools would then to something like 2 - 200, in which case you would choose something from 201 to 254. Others might have a pool of 50 to 200, in which case you could go under 50 or above 200. You just have to see what your pool is.

 

Some routers will let you choose anything you want and not assign that address to others, but unless you know for SURE yours does that I think it is best to assign an address outside the pool.

 

How to know the MAC address? Most router will have a table of current leases some where in their web page. So before assigning anything check the table and look for the IP address of your endpoint and the table should have the MAC address.

 

John S.

[DRVaudio]

Thank you for getting me started. I will go "off-line" for a while and get myself educated on optimizing my router. I will let you know, sometime soon, if I am able to resolve the "track stopping" issue.

[Superdad]

On 10/3/2021 at 2:10 PM, DRVaudio said:

The B-side of the ER is connected to a SoTM sMS200ultra (using the latest Eunhasu software), which is connected to an isoREGEN. The DAC is a DSD-only Lampizator with a super-amanero card.

When we spoke on the telephone I don’t recall you mentioning us of an ISO REGEN as well.  
Although what you report may seem like a network/EtherREGEN issue, there is also a chance that the extra isolation/ground lift is giving some fits. As part of troubleshooting please test without the ISO REGEN—and/or put the red switch of the ISO REGEN in the up (‘ON’) position, to defeat that unit’s galvanic isolation feature. 

[DRVaudio]

At the time of our telephone conversation, the ISO REGEN was not in the circuit. I will try with the red switch in the "on" position. This afternoon the tracking and internet was very stable. This evening it started going off line and giving me the ROON "track is loading slowly error".

[DRVaudio]

The internet connection to the EtherREGEN has been stable. I have not yet attempted to deal with the "leasing issue". Currently, (with and without the ISO REGEN, ROON is stopping/skipping tracks and periodically losing connection to the sMS200ultra (which is now at the current firmware version).

[Superdad]

I seem to recall you saying (on the phone) that your issue does not occur if you use the built-in Ethernet port of you music server instead of the JCAT network card.  Is that correct?

Also, please report what color the LEDs are above each occupied port on the ‘A’ side of the EtherREGEN.

[DRVaudio]

There are 3 A-side connections all are blinking when ROON is working properly.

My Desktop PC: green

Music Server PC: amber

To Router: amber

Currently ROON will track properly for several hours 7 to 10 and then skip a track or give the message "audiofile loading slowly". During this time the B-side has a constant amber light and a blinking green light. When ROON is working properly both lights are constant.

[JohnSwenson]

9 hours ago, DRVaudio said:

There are 3 A-side connections all are blinking when ROON is working properly.

My Desktop PC: green

Music Server PC: amber

To Router: amber

Currently ROON will track properly for several hours 7 to 10 and then skip a track or give the message "audiofile loading slowly". During this time the B-side has a constant amber light and a blinking green light. When ROON is working properly both lights are constant.

On both A and B green means 100Mbit and amber is Gigabit on the ‘A’ side. There are different chips on the two sides so the behavior is a little different. On the A side the amber OR the green light will be on, flickering when packets are going through. The flickering is NOT the actual packets, but the chip turning the LED on and off at a steady rate when packets are going across. On the B side the solid amber light means it is 100Mbit and the green light is the activity light. In this case it actually flickers with the actual packet rate, so when lots of packets are going through the light seems to be on solid. You see it flickering when the packet rate is very low.

 

This seems to match the message, that data is still flowing but going slowly.

 

So this probably rules out things like DHCP lease issues, which would stop the flow altogether. So it seems that data is flowing, just slowly. There seems to be two possibilities here: some sort of protocol issue that causes the data to flow slowly, OR some sort of network hardware problem that is causing partial hardware failure, not enough to cause complete failure but enough to cause SOME issues that are slowing things down significantly.

 

John S.

[Superdad]

9 hours ago, DRVaudio said:

Currently ROON will track properly for several hours 7 to 10 and then skip a track or give the message "audiofile loading slowly".

I ask again if the issue still occurs if you use the built-in Ethernet port of you music server instead of the JCAT network card.