Maybe using Devialet as player is a great options when we use less powerful Antipodes such as EX.
I tried that with the CX and I prefered the initial option of having the CX working as the server and the player.
I confess that I never used the K50 as server and the Devialet as player. I believe I would be using only 50% of K50 potential.
The AES/EBU output to Devialet is amazing. This is the setup I will keep.
Ah, but did you use a wired connection or wifi.? In my experience wifi is significantly better than wired when connecting to Devialet Pro.
A possibility is to change to a server only K model, sell the K50 and have extra funds.
Ditto. I was quite surprised by this. Perhaps the SSD I’m using is not optimal?
Ditto re minimising K50 reboots. Interestingly (or not) one time I thought I was playing music from the SSD while swapping switches but I was actually streaming from Qobuz because the music stopped about one minute after unplugging the switch. Left me wondering about remits of reclocking asynchronous data streams upstream of the K50 as many high end audio grade switches have clocks (though not the Medco switches).
1 Like
Ie….a fair of buffering happening inside the K50.
As I understand it all switches receive data transmissions, store the data packets (while working out where to send it and waiting to send it), and then sent the data in a transmitted analog signal, so they have:
-
clocks, to govern the frequency of transmission of data packets, but they don’t reclock (like the K50 reclocker that outputs a ‘stream’ of data)
-
RAM/memory to store data before sending.
The intent of a ‘better’ clock is to reduce phase noise of the transmission of data packets but does not affect the actual data (eg. audio data) in those packets. There is rafts of chatter about clocks on the likes of Audiophile Style AfterDark Audio pages, mostly about external reference clocks. Uptone Audio webpage about EtherRegen states:
There are two types of sound-degrading influences the EtherREGEN is designed to radically decrease: Leakage—both high-impedance and low-impedance—and clock phase-noise. The clock phase-noise travels on the Ethernet signal itself and on power- and ground-planes. [Every signal edge coming out of any digital device carries the jitter/phase-noise of the clock used to “clock out” that edge; this shows up on the ground-plane and affects the threshold of chips’ clock inputs. This is an oversimplification of a complex subject; here is the link to our ‘white paper’ about the technical mechanisms (to be followed with some measurement proof of the effects).
(Source: EtherREGEN – UpTone Audio)
For some back to basics, these seem good intros to switches and network architecture …
2 Likes
Yep and on many other websites…and to be honest all very confusing/misinformed. What you have laid out very clearly makes good sense…and I can now see why many different issues have been conflated (including in my own head!) in discussions round clocking. Thank you for the thorough explanation.
Folks, I’m just going to throw this out there: so much of the performance of an network is how the hardware is handling multi-cast traffic and not the quality of the network hardware itself (controversial, I know 
). I have run into conflicting recommended Multi-cast/IGMP settings from different DAC/Server manufacturers but I can attest to much better performance once the Multi-cast settings are working optimally.
The recommendation for most residential users is to use un-managed switches. In this scenario, you have zero control over Multi-cast behavior. I do wonder if the conversation about better network hardware isn’t a bit misguided. At least, the issue may be a combination of hardware and software configurations. But there shouldn’t be anything terribly mystic about networking
How were you able to arrive at this conclusion? Which are the audiophile network switches you’ve heard that you based this on?
While I have yet to configure this myself, it is my understanding that cutting down on network traffic can benefit sound quality. Mulitcast can be awfully chatty so one would have to block it from reaching one’s server but that can cause discovery problems.
What do you mean by performance? Multicast exists to facilitate discovery. Services announce their existence on the network so that other services can find them. This announcement only gets transmitted on networks that support multicast. It’s been my experience that this either works or it doesn’t as it’s an on/off thing.
It’s the router that offers control over multi-cast behavior.
While my intention is not to introduce an argument, to answer your questions: I’ve used the Nordost QNET, Melco S100, and a couple of Ansuz. And I’ve compare the “sound quality” of each of these switches to the Ethernet output of the K50, K40 and S40. I do not have experience with many of the other audiophile switches and tweaks on the market.
Correct, Multicast is first turned on on the router but IGMP snooping is set per switch, though a router with multiple LAN ports may offer IGMP settings. Querier settings seem to affect many streamers, the most sensitive I’ve yet played with being the Merging+NADAC. Performance in this case being audible ticks and pops that were removed with correct IGMP settings (it’s not clear to me if these were packet errors)
I would assume different brands of networking hardware negotiate Multicast traffic better or worse than others. But, if I’m not using managed switches, I generally turn Multicast off on my router.
Again, I’m not saying there aren’t audible benefits with different switches–I’m a huge advocate for better hardware in any scenario!–but I would like to see manufacturers discuss their software changes, if any are employed.
I apologize if my reply seemed argumentative. I was just trying to figure out how to interpret your claim. I still don’t understand what you mean by the following…
When audiophiles consider network hardware, quality is assessed by sound quality improvements. Handling of multicast is more about just getting things to work. I could easily cause a lot of things to not work by turning off multicast on my router, but if music continues to play there will be zero degradation in sound quality (though possibly a slight uptick). But if I were to swap in a lesser quality switch for my EtherRegen, the degradation would be noticeable. My position would thus be the exact opposite of your quoted text above, but that’s because I’m taking about sound quality performance.
As an aside, it astonishes me as to how much my EtherRegen can impact sound quality even when playing music off the K50’s drive. Even the dang DC cable feeding the EtherRegen can be found to have a noticeable contribution. Same for the reference clock cable.
Ah, yes I’m not as clear as I should have been. My point is if I can resolve a very audible problem by way of corrections to software settings (in this case, in relation to multicast/IGMP snooping), I suspect these settings can have an affect, subtle or not, across the board. In this case, it’s not a matter of how good the power supply or precise the clocks are, it was clearly a matter of poor network settings/software. I should note, there were no other indicators that this particular network was malfunctioning and the changes I made to the Querier State were in fact at odds with one manufacturers recommendations (hence why I don’t necessarily believe all manufacturers claims ). Modern residential networks in my neck of the woods are far more convoluted than users know. Multicast is employed everywhere
I have heard utterly bizarre and eye opening improvements from some network devices. Conversely, I’ve been left very underwhelmed by other well regarded products. But because there doesn’t seem to be any universal gains to be had with network accessories, clearly there’s more work to be done!
Cheers
Thanks for clarifying. I agree that there is more work to be done, but I also don’t think that we can expect these network enhancements to provide consistent benefits from network to network as there are just so many variables.
1 Like
I have zero network management skills, but remember my dealer warning me against multicast some years ago, though sadly, we never got to configure their recommended router (Draytek).
But this inspired me to look into this area, and I found the IGMP settings, and disabled IGMP Proxy and IGMP Snooping on a Draytek Vigor2862. It is hard to quantify how great the change is, but the sound is smoother and richer…sounds less ‘digital’.
It may be worth stating that I am still sticking with Roon/Squeeze, running on an Oladra, with AES/EBU going to Devialet Amps.
Very nice uptick.; thanks for the nudge to try it.
Next rabbit hole involves testing whether using file or Roon metadata on import makes a difference…
1 Like
but I also don’t think that we can expect these network enhancements to provide consistent benefits from network to network as there are just so many variables.
Hey Kenny,
Well said … not sure lucky or unlucky and while I understand ripping quality, my overall experience on music playback from 8TB SSD does not sound better than my streaming Qobuz and even free internet radio station which is contrary to what I have been reading here.
Streaming sounds more expansive, detailed and I even dare say more organic … any clue on root cause that I can try to fix ?
Cheers.
Too many variables are unknown to me to be able to speculate.
1 Like
Hey Kenny,
Understand … perhaps I can rephrase my query … anything detrimental to ssd playback by vanilla squeezelite that you can think of other than ripping quality that I had assured ?
Cheers.
Which power cords are you using with the EX and CX?
Hi Kenny,
All AC powered by Zonotone Shupreme 7NPS found here:
https://zonotone.co.jp/en/products/power-cbl-en.html
Trouble is that both ssd playback and streaming are with same powercords if indeed related to powercords for the oladra upgraded cx and ex 🥲
Thanks and cheers. 
Richard
Process of elimination, so I first had to understand which cords were used and if they were matched. Like I said, too many variables are unknown to me so it’s tough for me to speculate.
Ken
1 Like