Jump to content

JohnSwenson

Members
  • Content Count

    1631
  • Joined

  • Last visited

About JohnSwenson

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi All, Here are some more focused procedures to try for those of you having connection issues. First off, I want to establish general network connectivity without bringing audio protocols into this, i.e. make the network connections work first, THEN try and play music. With this we can separate issues with network connectivity from things like Roon or LMS etc. To do these tests you will need a way to find the IP addresses of your devices (servers, endpoints, etc.) and be able to "ping" them. A ping just sends a command to a device that says "send me a reply." This is a low level test to see if the communication is working at all. Fortunately there are some tools that make this fairly easy. I'm just going to list one for Windows and one for Mac; there are MANY others. Use what you wish. Nenon mentioned one for iOS, (thanks Nenon for helping with this, we really appreciate it). Windows : https://www.advanced-ip-scanner.com Mac: https://www.iwaxx.com/lanscan/ These programs will scan your network and show all the devices, including name and IP address. They allow you to ping the device and make sure it is responding. Some of the names are really weird and you may not be able to identify your devices. If this is the case, turn off your audio related devices (NAS, server, endpoint etc) and do a scan. Then turn on one device, do a rescan, note what was added--and do this for each device. Write down the name and IP address of the audio related devices (you don't need to write down phones, TVs, printers, ovens, toasters etc.) What I want you to do is run this process WITHOUT the EtherREGEN in the network. Take it out, turn off all the audio devices, turn them back on (no particular order) then run the scan, write the names and IP addresses down, do a ping on each device, make sure they all respond. Then put the EtherREGEN in the network and do the process all over again. See if any of the IP addresses have changed and if they can all still be pinged. If the devices still respond to a ping, start playing music, when you have the connectivity issues, do the scan again and check the pings. Note if any of the IP addresses have changed This information will be a really good starting point for finding out what is going on. Thanks, John S.
  2. Hi Dutch, Yes I have extensively tested multicast and mDNS, they both work fine in every scenario I've tested. BTW, there is only one switch in the EtherREGEN--in the A side. One of the ports on the A side switch sends data through the "special sauce" which goes into a format converter which is not a switch. Whatever packets come in go out without any modification. John S.
  3. For all of you having problems with droputs and disconnections I think I have figured out what is happening. A little background first: the endpoints most people use get an IP address from a DHCP server on your network (usually in the router). The DHCP server creates a "DHCP lease" which itsends to the endpoint, this contains an IP address and a range of time it is good for. When a music server connects to the endpoint (each protocol does this part differently) the endpoint sends this IP address to the server, which then uses it to talk to the endpoint. The fun part happens when the lease expires, the endpoint then goes back to the DHCP server and says "renew my lease", in most situations the DHCP server will give it back a new lease with the same IP address it gave it the first time. BUT sometimes the new lease contains a different IP address, this is what causes the problem. The server keeps on sending the audio data to the old address, but the endpoint doesn't get it because it now has a different address. The music data goes into Ye Olde Bit Bucket. Somehow the music server has to get the new IP address of the endpoint. There are a few ways of doing this: turn off the endpoint then turn it back on (unplug it, many endpoint's power switch just puts them in low power mode), sometimes this may need to off for 10 to 15 minutes. Unplug the Ethernet cable for 10 to 15 minutes. Reboot the music server This gets the server back talking to the endpoint. In many instances this is all that is required, from then on the DHCP coninues to renew the lease with the same address it gave out the second time. For some systems it might take two times for the DHCP server to settle down. Another option is to make sure the address of the endpoint never changes, there are two ways to do this: set a static IP address on the endpoint. Not all endpoints allow you to do this. Set a reserved IP address on your DHCP server, almost all allow you to do this, the endpoint still asks for a lease or renewal, but you reserve a specific address for that specific endpoint, the DHCP server HAS to always use that one. Most people's system do not have the problem in the first place. For the ones that potentially do have this issue there seems to be some sort of trigger that causes the DHCP server to behave this way, it usually has to do with something "new" in the system. A new endpoint will almost always trigger this. Sometimes the same endpoint but with a different configuration, or a network with a significant change. Simple switches will usually not trigger this, but managed switches (or different configuration of the same switch) being added, or taken out can also trigger this. So while this seems to happen when you add the EtherREGEN it is probably not anything inherently wrong with the EtherREGEN, but rather that you have significantly changed your network topology that is somehow triggering this behavior in t your DHCP server. Ether just living with it until the DHCP server settles down or clamping down the IP address of the endpoint should get rid of the issue. If you want to spend time playing with different network configurations, endpoints etc, I would recommend you reserve the IP address of your endpoint so the DHCP server cannot mess you up in the future. Note: I do not know exactly what the triggers are or exactly how the DHCP server determines when something is "new". And most likely different models behave differently. So please don't ask questions like "will my system have this problem?" "Exactly what do I do if I have it?" "Which router should I buy so it won't happen to me?" I don't know the answers to those questions. Tomorrow I probably will not know the answers either. So please don't ask. What I know about it is already in this post. If you do have the problem and you follow the advice above and it does not go away, please post THAT, we will try and get to the bottom of it. John S.
  4. Did you try using the supplied SMPS powering the EtherREGEN when going router->A B->DAC? Are your Ethernet cables shielded using metal connectors? This is actually sounding like ground loops. John S.
  5. Yes, you cannot connect the RJ45 jack of the opticalModule to the RJ45 "B" jack on the EtherREGEN. The oM RJ45 jack just runs at gigabit and the RJ45 B jack on the EtherREGEN only runs at 100Mb. The EtherREGEN was specifically designed so you can run it "backwards" when driving a device such as the opticalRendu.
  6. I looked at that page, and it is all based on how 100Mb Ethernet works, NOT gigabit. This could actually be harmful to a gigabit circuit. I would never use something like this. I'm not even going to speculate, it is just a plain BAD IDEA. John S.
  7. One other bit of information: when you are having dropouts are they randomly distributed or do they occur at a specific time? The first and last ten seconds of a track are the most likely to have dropouts. During the last ten seconds of a track the player starts filling the buffer for the next track which is much more intensive than "normal" Ethernet traffic which has significant space between packets.The first ten seconds is where things like metadata and cover art gets sent. Thus far more net activity happens at the end and beginning of a track. Just general information: it is usually best to have the EtherREGEN powered up before other devices are turned on/plugged in. I HAVE seen a couple times that if the EtherREGEN is turned off and other devices connected/powered up, one of the devices can power down because it is not connected to anything. The are SUPPOSED to notice when the switch starts trying to connect and power up again, and most of the time it does, but I have seen a couple times out of thousands of connections the device doesn't connect when the EtherREGEN powers up. Trying again always fixes it, but if you want to make sure that doesn't happen, have the EtherREGEN on when connecting or powering up the other devices. John S.
  8. I presume you are using the Roon emulation of LMS, correct? I'm wondering if this has anything to do with it. I've been using LMS with an SBT for a couple months without any such issues, I don't have a Transporter to test with though. Is it possible to try switching to real LMS on your Sonic Transporter and see if that has the same issues? John S.
  9. I'm still in the process of writing the paper that goes into great detail about all this. I wanted to include some actual measurements of systems with and without the EtherREGEN, but I'm having some trouble getting measurements made. The super sensitive jitter analyzer I recently acquired cannot be directly connected to the circuits, I have to build an interface circuit and the first one did not work, I've designed a completely new one which should not have the problems of the first one, but the board has not come yet. With the holiday it won't be here until Tuesday, then I have to solder all the parts in etc, that will take a little while, then try and get it to work properly with the test equipment. Its all taking much more time (and money) than I had hoped. So I'm not sure whether I should just finish the paper and post it or wait for real measurements. John S.
  10. What you are describing is probably the best way to go. In this case most of the packets are going to the endpoints, hence crossing the moat, thus there should be little interaction between endpoints. That is certainly how I would connect things. John S.
  11. The A side RJ45 jacks are 10/100/1000, the A side SFP port is just 1000, The B side RJ45 is 100. That's the way it is, there is no way to change any of that. John S.
  12. This is most likely a misconception concerning things like "depleting bass". Some things in software actually change the bits such as filtering, upsampling, converting to DSD etc, these things the EtherREGEN does not affect at all, it does not change the bits in any way. You mention things like digital cables etc depleting bass, this has nothing to do with bits being changed. It is all about some form of noise (usually either voltage noise or phase noise) hitching a ride along with the digital data (the bits) and getting into the DAC. This causes very small distortions in the analog signal which somehow cause the human perceptual system to hear "depleted bass". It really isn't depleted bass, if you measure the actual audio signal the frequency response doesn't change, but those specific small distortions cause your perceptual system to hear it that way. (there is way more to this than just bass). THAT is what the EtherREGEN is all about. Getting rid of those noise components before they reach your DAC. Note: this has absolutely NOTHING to do with the data in the bits, it is all about various types of noise carried along with the bits, let me repeat it has absolutely NOTHING to do with the bits! The DATA stays the the same. I'm writing a paper right now on how all this works so I'm not going to go into details here. I understand this can be hard to grasp, you think something upstream of the DAC caused the bass to go away so how can anything down stream put it back? Because the upstream component DIDN'T get rid of the bass, the bass is still there in the bits, what it DID was add some noise which upon reaching the DAC causes small distortions in the audio which your perceptual system interprets as the bass going away. John S.
  13. 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.
  14. Yes, correct. There is the one power LED and the LEDs on the RJ45 jack. The chip we are using does not have LEDs for the SFP cage so you can't tell if that is connected or not, other than sending data. John S.
  15. The EtherREGEN does not have an ip address, there is nothing inside that CAN be addressed. We have set it up so it is an un-managed switch to make it simple to use. It itself does not have an address, it will never ask for an address and it can never send an address to anything else. It is possible to change the behavior by changing the firmware using the USB port, but that will only happen when we decide to make a change and provide the file to users. There is no way for the users to create their own modifications. This mechanism is designed for the scenario where users find an issue where it does not work in their system and we can fix it by making a change to the firmware. We are going to be very conservative in doing this, we don't want to break something for most people in order to fix an issue for one person. John S.
×
×
  • Create New...