No, that does not seem normal and I have never had that with my PhoenixNET. Is there any chance you changed anything else at the same time, possibly accidentally?
To switch or not to switch? Melco S-100 or Innuos Phoenix NET switch?
- Thread starter shakti
- Start date
I wouldn’t describe the initial hour or two as totally distorted. I would say that musically it can sound very ‘Off’ and uncomfortable in that certain frequencies are emphasized. It takes a couple of hours to sound good(ish) then about 3 days to sound very nice with clear improvements but still with running in anomalies that takes a few weeks to completely even out. I just upgraded my DC4s with ARC6. Initially it sounded like I was standing next to a Category 5 musical tornado with huge, unbounded energy but that soon settled down to sound really great for a few days before burn-in took over and some of the magic disappears. Running in is a bit of a roller coaster ride so be patient and keep the PPP (post purchase paranoia) under control.
I have three dedicated Ethernet switches plus a Waversa Wrouter which I use only as a switch. The system Router is Ubiquiti Unifi Dream. The three other switches are the Melco s100 unmodified, SOtM sNH-10G +sCLK_EX, and a Paul Pang Quad. The Melco and the SOtM each have a separate LPS. As well there is a Waversa EXT Reference Filter with an Ethernet cable going to a WEISS DSP 502. I have had other switches in the past but due to space limits I no longer have them. I have not tried the Innuos. Switches connected together for me provide a benefit.
Besides the benefits of the switches etc above, there is something even much more important to me for my system with a recent change. Cables. All of the components are connected via Acoustic Revive red cable with Telegartner plugs. The cables are assembled in Australia. I recently had the shield on one cable at one end disconnected. That becomes the receiving end. I noticed an improvement in SQ with the disconnection. So, I had another done. More improvement. I then had the same done to the other eight cables that I have. The SQ benefit from a significant decrease in the noise floor with the use of the cables is amazing. Probably the best audio single step improvement I have ever done.
John
Besides the benefits of the switches etc above, there is something even much more important to me for my system with a recent change. Cables. All of the components are connected via Acoustic Revive red cable with Telegartner plugs. The cables are assembled in Australia. I recently had the shield on one cable at one end disconnected. That becomes the receiving end. I noticed an improvement in SQ with the disconnection. So, I had another done. More improvement. I then had the same done to the other eight cables that I have. The SQ benefit from a significant decrease in the noise floor with the use of the cables is amazing. Probably the best audio single step improvement I have ever done.
John
Greetings everyone. I have an update for this thread. I have some really good news, and some bad news (really... it is just ABA testing delay)
Good news: my Innuos PhoenixNET arrived this Wednesday (3-days ago), and it was promptly inserted into the following playback chain:
New 'Current State' of Digital Front-End: ISP Modem (JS-2 LPS) -> eRegen (JS-2 LPS) -> PhoenixNET -> Zenith Mk3 -> PhoenixUSB -> BC-515 DAC
Re-Tread I notice in your setup you are running a JS-2 for the Modem and eRegen. Is that two different JS-2's or a single JS-2 using dual outputs? If it's the later, then you are defeating the purpose of the 'moat' in the eRegen. Alex Crespi has specifically told me not to do this, not to power the eRegen AND a device on either side of it with the same JS-2. Noise will jump the moat via the JS-2 as it is powering both sides.
Maybe you can bring in another spare LPS and see what occurs. Could be more sonic gains for you.
Greetings @agisthos,
I will try my best to describe my implementation: I use only a single JS-2, which is a dual-rail LPS (as you know). Rail #1 is set for 12v, and powers my Netgear CAX30 cable gateway modem (with Broadcom chipset, with WAP turned OFF to lower noise). Rail #2 is set for 12v, and powers my eRegen. The Netgear CAX30 modem is immediately "upstream" to the eRegen, and it connects to the "A" side of the eRegen via copper ethernet port. The modem is the only device I have connected on the "A" side of the eRegen. Moreover, the JS-2 is not powering any devices connected to the "B" side of the mote. Thus, no noise contamination issues should arise from the grounding plane of the JS-2 "crossing" the mote.
I did talk to @Superdad about this a while ago (~ 2 years ago), and he said my arrangement is fine, because the JS-2 is not powering devices on "both sides" of the mote. That said, I am certainly open to learning something new . See my signature for my latest system details.
Hope that context helps. Perhaps @Superdad will chime in, if he sees this...
Retread
I will try my best to describe my implementation: I use only a single JS-2, which is a dual-rail LPS (as you know). Rail #1 is set for 12v, and powers my Netgear CAX30 cable gateway modem (with Broadcom chipset, with WAP turned OFF to lower noise). Rail #2 is set for 12v, and powers my eRegen. The Netgear CAX30 modem is immediately "upstream" to the eRegen, and it connects to the "A" side of the eRegen via copper ethernet port. The modem is the only device I have connected on the "A" side of the eRegen. Moreover, the JS-2 is not powering any devices connected to the "B" side of the mote. Thus, no noise contamination issues should arise from the grounding plane of the JS-2 "crossing" the mote.
I did talk to @Superdad about this a while ago (~ 2 years ago), and he said my arrangement is fine, because the JS-2 is not powering devices on "both sides" of the mote. That said, I am certainly open to learning something new
. See my signature for my latest system details.Hope that context helps. Perhaps @Superdad will chime in, if he sees this...
Retread
Last edited:
Out of curiosity, what is the point of inserting the eRegen in the chain here, if you are going to use the PhoenixNET? Isn't this redundant? Sorry if this is a stupid question, considering a very similar set up.Greetings Exlibris,
To refresh the context of my use-case, this is my "current" and "future" states of my digital set-up:
* Current: ISP Modem (JS-2 LPS) -> eRegen (JS-2 LPS) -> Innuos Zenith Mk3 -> PhoenixUSB -> Blue Circle DAC (custom)
* Future: ISP Modem (JS-2 LPS) -> eRegen (JS-2 LPS) -> PhoenixNET -> Innuos Zenith Mk3 -> PhoenixUSB -> Blue Circle DAC (custom)
All signal cabling above is from FTA (Final Touch Audio, a small purveyor from Serbia). Their ethernet cable model is called "Metis"; and their USB cable model is called "Callisto". I believe they are on par similar to the likes of Sablon and/or Shunyata... from reports I have read.
I can report the eRegen employed now (in the current state) brings a very positive sonic uplift to my digital front end. My hope is that the eRegen will positively cascade in combination with the (future state) PhoenixNET, when inserted. I will have to be patient to let the PhoenixNET fully break in (~ 450 hours or so) before final system assessment. Fingers crossed the combination with be better than either alone.
So I am now eagerly committed, as I have recently ordered my PhoenixNET (i.e., paid my Innuos dealer), so now I am just waiting on the production/delivery. The lead time is uncertain, but will be clarified soon, as Innuos told me there may be a delay in the supply chain. It could potentially be 2 to 5 weeks before I receive it. Either way, no problem.
On a sidenote: I have been a distant, long-time admirer of your system on AG. It is very beautiful, indeed. All of your equipment looks like it has great "intention". And I love your architectural back wall, and the low stance of your equipment in your room. I remember when you had an AN M6 preamp, (I think) AN speakers, and your equipment was stacked on uneven wooden blocks. Your system has evolved quite a bit since then. Your Thomas Mayer equip must be simply amazing (spellbinding, is the word that comes to mind).
Re-tread
Greetings @Ratbastrd ,
On the surface your question is valid: Why have 2 devices in series that "on the surface" appear to do the same thing (i.e., mitigate noise on the ethernet "signal"). Well, as it turns out (from my experience, and many many reports by others who have also tried) cascading multiple "high quality" switches in series has proven to provide an aggregate sonic uplift that is better than either switch operating alone. Even though each switch (in this case, an eRegen, and a PhoenixNET) is completely competent on its own, the compounding affect of having them COMBINED (in series in a controlled environment) yields a better uplift than either one alone.
To see my notes of my experience, kindly refer to this posting if helpful:
www.whatsbestforum.com
NOTE: IMHO, one key recommendation here (when trying this) is to be sure to give all your ancillaries (e.g., DC cables, PC's, LPS's, switches, etc.) adequate time to fully break-in and settle before making any final performance judgements. Sometimes these sensitive ancillaries take several hundred hours to fully break-in (e.g., their capacitors, dialectics, transformers, etc.). What may sound harsh at 25-hours, may smooth-out and bloom at 400-hours. That said, your first plug-in should be a good indicator of the direction you are heading before the "break-in" rollercoaster begins.
Hope that helps to answer your question.
Retread
On the surface your question is valid: Why have 2 devices in series that "on the surface" appear to do the same thing (i.e., mitigate noise on the ethernet "signal"). Well, as it turns out (from my experience, and many many reports by others who have also tried) cascading multiple "high quality" switches in series has proven to provide an aggregate sonic uplift that is better than either switch operating alone. Even though each switch (in this case, an eRegen, and a PhoenixNET) is completely competent on its own, the compounding affect of having them COMBINED (in series in a controlled environment) yields a better uplift than either one alone.
To see my notes of my experience, kindly refer to this posting if helpful:
To switch or not to switch? Melco S-100 or Innuos Phoenix NET switch?
Report Update (continued from entry #131 above): Greetings all. I have now done some initial testing of A-B-A Test 2, so I will re-iterate the digital baseline again for clarity: New 'Current State' of Digital Front-End: ISP Modem (JS-2 LPS) -> eRegen (JS-2 LPS) -> PhoenixNET -> Zenith Mk3 ->...
www.whatsbestforum.com
NOTE: IMHO, one key recommendation here (when trying this) is to be sure to give all your ancillaries (e.g., DC cables, PC's, LPS's, switches, etc.) adequate time to fully break-in and settle before making any final performance judgements. Sometimes these sensitive ancillaries take several hundred hours to fully break-in (e.g., their capacitors, dialectics, transformers, etc.). What may sound harsh at 25-hours, may smooth-out and bloom at 400-hours. That said, your first plug-in should be a good indicator of the direction you are heading before the "break-in" rollercoaster begins.
Hope that helps to answer your question.
Retread
Last edited:
Interesting. Aren't you concerned about packet loss or jitter with all the switching going on? While minimal, I would think that there is room for degradation of data if the switches can't keep up with the data flow.Greetings @Ratbastrd ,
On the surface your question is valid. Why have 2 devices in series that "on the surface" appear to do the same thing (i.e., mitigate noise on the ethernet "signal"). Well, as it turns out (from my experience, and many many reports by others who have also tried) cascading multiple "high quality" switches in series has proven to provide an aggregate sonic uplift that is better than either switch operating alone. Even though each switch (in this case, an eRegen, and a PhoenixNET) is completely competent on its own, the compounding affect of having them COMBINED (in series in a controlled environment) reaps a bigger uplift than either one alone.
To see my notes of my experience, kindly refer to this posting if helpful:
To switch or not to switch? Melco S-100 or Innuos Phoenix NET switch?
Report Update (continued from entry #131 above): Greetings all. I have now done some initial testing of A-B-A Test 2, so I will re-iterate the digital baseline again for clarity: New 'Current State' of Digital Front-End: ISP Modem (JS-2 LPS) -> eRegen (JS-2 LPS) -> PhoenixNET -> Zenith Mk3 ->...
NOTE: IMHO, one the keys here (when trying this) is to be sure to give all your ancillaries (e.g., DC cables, PC's, LPS's, switches, etc.) adequate time to fully break-in and settle before making any final performance judgements. Sometimes these sensitive ancillaries take several hundred hours to fully break-in (e.g., their capacitors, dialectics, transformers, etc.). What may sound harsh at 25-hours, may smooth-out and bloom at 400-hours. That said, your first plug-in should a good indicator of the direction you are heading before the "break-in" rollercoaster begins.
Hope that helps to answer your question.
Retread
No. I have not experienced any packet losses (that I am aware of), or noticed data flow issues in my audio playback. On the contrary, (and this may sound counter-intuitive), as the quality of sound "up lift" goes up from each switch, it gives me more confidence that jitter is being reduced through each successive "audio grade" switch (as each switch re-clocks the data "signal" with low phase-noise oscillators and finely-regulated linear power supplies). It is like the data "signal" leaving each switch is in better qualitative condition (for audio playback) than before it arrived. And, the SQ uplift from each switch aggregates successively.
I am not an engineer, but my ears tell me the quantitative aspects of the digital "signal" are completely intact, however concurrently, the qualitative aspects are enhanced (lower noise, increased dynamics, more ease, less digital, etc.). I know that may sound counter-intuitive to the KISS model, but it works for my system and many others. That is the reason for doing it. You can read much more on the topic on this forum and at Audiophilestyle forum.
audiophilestyle.com
All that said, the "audio grade switch" product landscape is advancing rapidly, and in the not too distant future, we may have a single device that supersedes the need for multiple, cascading switches.
Hope that feedback (and very un-technical quasi-explanation) is helpful.
Retread
I am not an engineer, but my ears tell me the quantitative aspects of the digital "signal" are completely intact, however concurrently, the qualitative aspects are enhanced (lower noise, increased dynamics, more ease, less digital, etc.). I know that may sound counter-intuitive to the KISS model, but it works for my system and many others. That is the reason for doing it. You can read much more on the topic on this forum and at Audiophilestyle forum.
Where Stereo and Immersive HiFi and High Tech Converge
Home to trustworthy coverage of 2 channel and immersive HiFi and high tech convergence through subjective and objective product reviews, how-to articles, and show coverage.
audiophilestyle.com
All that said, the "audio grade switch" product landscape is advancing rapidly, and in the not too distant future, we may have a single device that supersedes the need for multiple, cascading switches.
Hope that feedback (and very un-technical quasi-explanation) is helpful.
Retread
Last edited:
I don’t believe there is any correlation between packet loss and the number of switches - except for the fact that the chance of using a bad cable goes up when more cables are used.
Maybe, maybe not. While I'm not an audio expert, I spent many years in the IP communications networking space. I'm fairly certain that daisy chaining switches is introducing some form of degredation to the signal, which would logically be packet loss. And, whatever/wherever the first transcoding of the transport codec is occuring is likely employing some form of error correction. (ironically, and this is way over my head) I've long suspected that the source of debate between believers and non believers of cables imparting color into digital signal paths is actually this. Happy to explain more. It's not the cables but the error correction algorithm(s) imparting color into the audio.
Last edited:
Switches generally operate at level 2, the data link level. They read the packet's MAC address and then forward it on. There should not be degradation unless there is something wrong with the device or with the cables.
I think the biggest stumbling block for most naysayers is that they are unable to see that what are really talking about here are copper cables that transmit an analog waveforms. As with any analog cable, noise and distortions can come along for the ride.
If all you have is a hammer, everything looks like a nail. I think in the same way many audiophiles - especially those with a networking background - only look to the digital domain for an explanation. They fail to consider the fact that the OSI Model is comprised of 7 layers, the first of which is the physical layer. What follows in itallics is from the WikiPedia page of the OSI model. I look at this and it strikes me as foolish to think that what's happening at the physical layer couldn't have a detrimental effect on a high-end audio system unless it is properly dealt with. I'm not yet sure that daisy-chaining switches is dealing with it properly, but it is definitely having a positive effect for some. And as far as cables, these not only pass on noise but add some themselves. The better cables aim to address this and pass the signal at the highest fidelity,
The Physical layer is responsible for the transmission and reception of unstructured raw data between a device, such as a network interface controller, Ethernet hub or network switch, and a physical transmission medium. It converts the digital bits into electrical, radio, or optical signals. Layer specifications define characteristics such as voltage levels, the timing of voltage changes, physical data rates, maximum transmission distances, modulation scheme, channel access method and physical connectors.
Last edited:
Lets use a bit of logic here. If multiple switches cause packet losses, then so do single switches. A switch doesn’t start loosing packets just because its in the company of other switches. I am aware of extremely experienced audiophiles who are hugely experienced in networking….often around activities like finance and banking, where speed and integrity are massively important and where they actually make money by reducing latency. They have tried up to 6 switches in series to see how they affect both network performance and sonics. No reports of network losses or increased errors, but certainly very positive on sonic gains.
A network switch performs several roles. Obviously it switches network traffic, which partially isolates and reduces traffic to other parts of the network. Reduced traffic means less noise.
As long as there’s no ethernet cable continuity, it provides partial electrical isolation to downstream components, it provides a degree of noise filtration, it retimes the packets and it resynthesizes the data stream using its own power supply. So if the switch uses a really good power supply and has a high quality chrystal oscillator, all downstream traffic is quieter, with less noise, with more accurate encoded voltages, and with more accurate timing. The output of the first switch is therefore very much an improvement over its input. In hi-fi, better in = better out, so the improved output from the first switch provides a much more refined input to switch #2, which adds its refinement and outputs an improved stream (vs switch #1) which then feeds switch #3. Now let’s take the output of a router. Let’s say I place the router on a vibration isolated platform and power it with a very low noise, highly refined power supply. The router’s output is already improved by those measures and this improved signal hits the first switch, which again uplifts its quality. The improvements you made to the router are therefore compounded again and again by the 3 downstream switches.
Finally, while data only cares about all the bits being present, audio very much depends on the physical quality of the digital data stream, in whatever form. In hi-fi better in always equals better out and that’s no less true for the ‘physical fabric’ of the digital data stream. The less noise, the fewer timing inaccuracies, the less interfering non-audio traffic, the less vibrational losses, the less cable losses, the less ground plane noise the better the audio sounds. Adding multiple switches with good power supplies has a major positive impact on sound quality because when correctly implemented, it has a major positive impact of the quality of the data stream.
Last edited:
Lets start with one truism. There is packet loss in EVERY network.
You are correct in your statement. Audiophile switches (as I understand them) are also doing traffic shaping (prioritizing audio traffic), isolating noise (emf) artifacts that are present on the physical layer, probably some other things.
But switches are like dams. By introducing a switch, users are intentionally creating a choke point for data flow (A bend in the river). The intention may be to improve the flow of traffic etc. However, by definition every hop in a network will introduce some latency (Jitter), and the potential for additional packet loss. This is the reason for traffic shaping in the first place.
By daisy chaining switches you are multiplying that effect down stream. And I am 100% certain that those variables will influence behavior down stream when the D/A conversion first takes place.
Think of it this way, you have an original painting, that is cut up into pieces, digitized, transported, unpacked (un-digitized) and then reconstructed. Only problem with the reconstruction is not all the pieces (packets) are there, and/or they are not all in alignment (in order of deconstruction). The first D/A transcoding has the same job as an art gallery that is repairing a painting. Where there are missing pieces, the artist repairing the painting (error correction algorithm) is interpreting from information nearby and "filling" in the blanks.
I suspect (just a guess) that the color users perceive as added space, clarity, lower noise floor etc, is in fact the error correction algorithms doing their job (correcting for lost or misaligned packets). If you break it down and think about it, it is really the only thing that makes sense.
Last edited:
Yes exactly
Not true. Decoding (headers) + prioritizing (reordering and adding priority information into the packet header) + re-transmitting + (filtering electronic noise on the phy layer) however many times this is happening is by definition introducing Jitter (latency & packet loss). You are interrupting the flow of millions of packets moving at incredible speeds, to reorder and retransmit. Take your earlier statement and multiple it. If a single switch causes packet loss (which it will, even if just a few), the multiple switches will multiply that effect.
Retimes and resynthesizes (reorder is probably a better word for it), switches are not decoding payload.
Again, switches are not decoding payload. What ever was there originally is still there, less the original number of packets, not necessarily in the order in which they were transmitted. The only thing a switch is doing here is improving timing by reordering and prioritizing packet flow.
Unless I'm missing something on the design of the switch? I think it would be called a DAC if what you saying is true.
By the way, what I am suggesting, doesn't necessarily refute this statement. It is important to understand I'm not suggesting that users perceptual experience of improved sound isn't occurring. This may in fact be absolutely true. Just not for the reasons you are stating.
It is entirely possible that multiple switches is forcing different behavior at the D/A process downstream. In effect by introducing jitter you may be forcing different error correction behavior in the D/A process. Who knows?
Last edited:
Similar threads
