Best audiophile switch
- Thread starter Frankie67
- Start date
Thanks, for sharing, Tom. Interesting, congrats for the system’s scheme!
Why not? I’ll try to enable the WiFi on my router tonight (disconnecting the controller’s cable), let’s give it another chance and listen… last time I compared enabled vs disabled was a year ago and many things are changed in my system in the meantime. I’ll keep you informed…
PS: I stream from Qobuz via Sense App 90% of the time, I rarely play ripped/downloaded files from the server. It means that it’s even more crucial in listening habits.
No worries, your setup effectively demonstrates how Wi-Fi is used between a router and wifi-satellite, though many of us rely on Ethernet or fiber connections directly to an eR (or another switch). In setups like yours, the placement of these devices is crucial to avoid cross-contamination and unwanted vibration, which could significantly improve sound quality. This also highlights that the performance of "the best audiophile switch" cannot be evaluated in isolation; it must be considered as part of the entire network configuration. A high-performing switch may excel on its own, but it is still just one element in a larger network chain before reaching the streamer/dac, and not a complete solution.
As a side note, one might argue that, ideally, the entire network chain should be irrelevant to the DAC’s output. While a direct, 100% noise-free Ethernet connection between the router, switch, and streamer/DAC is preferred, it’s surprising that by 2024, we still rely on a myriad of cables, filters, clocks, and switches. Ultimately, the only truly significant factor is the performance of the DAC—its clock and conversion— shielded from noise as much as possible (and the analogue signal coming out of it).
If altering any single element upstream like the router, switch, or cables, still affects the DAC's output, and many of us can hear that change, it suggests there is still room for improvement in achieving an optimal, noise-free setup.
Last edited:
FritzBox is the best option to choose for the ISP router/modem. There are newer models from AVM/Fritzbox that might also fit your needs.
Definitely have a look at the firmware tuning options for the Fritzbox like https://griggaudio.de/2022/08/30/fritzbox-audiophiles-setup/
Excellent point, but quoted from the website mentioned above please consider the following points:
Hi Tom,
Sorry if you already said, but did/do you have the option of having a direct Ethernet cable v.”WiFi moat”
I had a similar flow to your illustration, but only because I had just moved into a new home and didn’t have an Ethernet connection in my basement where my system is located. Having just had a cable brought from my upstairs office into the audio room, from a purely enjoyment perspective (no analyzing audiophile jargon) I am nearly convinced I prefer having WiFi only as access point and not in the signal path.
Let me also say that it didn’t cost me any time/money/hassle to have the Ethernet cable run so there isn’t any built in influence/bias to sway my perception as can often be the case.
I plan on revisiting the previous setup in a week or two to confirm and will report back.
Attachments
Not really, without doing some unneeded construction to hide said wires. I tried a hard connection but after a 100' run? I preferred the setup I now have. As an added bonus, the mesh network dramatically increased the performance of all other devices within the household that relied on wi-fi signals. Buffering is a thing of the past anywhere in the house or yard...on any device.
Tom
Tom
I live about 2 miles away from a US Military “Space Force” facility. While there is very little to no actual people/car traffic to interrupt daily life, the interference from their satellite/tracking devices wreaks havoc on cellular and WiFi connectivity. Even my garage door opener can be shaky!
Thought about often…and I am as prepared as one can be.
I have met quite a few “high uppers” retired military people that have seen for themselves and are also very privy to highly classified information and while they can’t be specific have given plenty of food for thought. Lots of weird unexplainable $*** going on.
Last edited:
...aliens love to rummage around in human garages. Usually on weekends. And those gaunt-eyed bastards will steal vintage hifi gear, FYI. Carry on.
Maybe helpful? Thread 'Which is the best SFP GPON module for Fritzbox 5590 fiber?'
Without having tried it myself, I would consider the Ubiquiti EdgeRouter ER-4 (same pricerange as Fritzbox). What I like, although not made for audio, it is specifically designed for routing, with no unnecessary functions to disable and comes with an SFP cage but internally powered. Afterdark offers a modified version of this router with better power, clock and shielding and more.
Last edited:
I'm using the Aruba AP22 access point.
I've tried stuff like with SoTM filter & Catsnake cable, without filter - SoTM ethernet cable, LPSU.
I can hear a difference on my wireless devices. My iPhone, laptop. etc. Streaming movies and playing spotify (basic task lol)
Your comment provides a clear and detailed explanation of how Ethernet's asynchronous nature affects timing and jitter, and why clock accuracy might not be critical before the data reaches the streamer. Here are a few points of critique and areas for further exploration:
- Assumptions About Jitter Impact: While you correctly state that Ethernet jitter is more about packet arrival times and less about timing accuracy affecting audio quality, it's worth noting that the quality of Ethernet components (including clocks) might still influence the overall system. For instance, if an Ethernet switch or network card introduces excessive noise or interference, it could affect the signal quality even if the data is eventually error-corrected.
- Quality of Electronics: Your argument focuses on the idea that better clocks are likely to contribute to lower noise in the circuitry rather than improved timing accuracy per se. However, it might be helpful to elaborate on how this noise reduction translates into perceived audio quality. The relationship between electronic noise and audio fidelity is complex and not always straightforward.
- Post-Processing Jitter: Your point about jitter becoming relevant only after the data is unpacked is valid, but the transition between Ethernet and the streamer can introduce other forms of noise or interference. Exploring how these factors interact might provide a more comprehensive understanding of where quality improvements can be most impactful.
- Manufacturer Responsibility: You emphasize the duty of manufacturers to ensure quality in the pre-streamer domain. It might be useful to discuss what specific aspects of pre-streamer equipment could be improved and how consumers might better understand these factors. For example, what should consumers look for in a high-quality network setup?
- Isolation vs. Clock Accuracy: While you agree with Hans’s position on isolation and noise reduction, it could be beneficial to explore why some manufacturers emphasize clock accuracy even in pre-streamer equipment. This might shed light on whether there are specific scenarios or setups where such claims could be justified.
Overall, your analysis is well-founded and aligns with technical understanding. Expanding on these points could provide a more rounded critique and deepen the discussion on the interplay between Ethernet, streaming, and audio quality.
@Openklasse
Thanks for your well-considered post.
1. I absolutely agree. If one clock is lower noise than another clock, it absolutely can affect sound quality. I think we agree that this is nothing to do with clock accuracy. I have tried to be careful (but may have slipped up occasionally by using shorthand) to criticise claims that ethernet clock accuracy can impact sound quality rather than to criticise clock quietness.
2. Agreed. Noise causes no harm while it rattles around in the ethernet space. It doesn't even do any audible harm at the streamer itself, but the streamer's main job is of course to repackage the ethernet packets it receives into a bitstream which the DAC will recognise and in its turn convert to analog(ue). If we can stop noise reaching the streamer, we can make a major contribution to sound quality because it won't be forwarded to the DAC where RFI noise becomes audible through its impact on the analog(ue) componentry. Sure, we should also pay attention to how much noise gets from the streamer to the DAC and the right choice of cable here can also make a difference, but the focus of the thread is on the ethernet space.
3. Agreed (again!). I'd love to learn more about post-conversion-to-bitstream jitter for the benefit of my own audio systems if nothing else but I have much more to learn in this space before I can comment with any confidence. I enjoy living and learning...
4. On the manufacturer front, I guess my plea to fellow manufacturers in the ethernet space is that they take the time to really understand how asynchronous ethernet is completely different from synchronous post-streamer digital and not develop and market solutions to real problems in the ethernet space. As we know that the 7-layer OSI ethernet protocol will ensure the data (in our case representing music but the protocols really don't care) gets to its destination, the only variable influencing sound quality is RFI noise: it can be environmental, it can come down a wire, it can come across the ground plane... but in the network/ethernet space noise is all we can control.
5. I really do think that many manufacturers who promote the "issue" of clock accuracy in the pre-streamer domain are extrapolating inappropriately from the post-streamer domain, where we all know jitter is an audible thing and high accuracy clocks can have an audible impact. They need to be challenged to explain how ethernet clock accuracy can possibly affect sound quality when the data packets are transmitted asynchronously, subject to error-checking and if necessary retransmission, and ultimately converted to a completely different bitstream format by a device which has its own clock! I've seen some misleading "explanations" which talk about digital data not actually being 1s and 0s but being transmitted as an analogue waveform with curves and approximations and whatever: it's another completely erroneous extraploation from the post-streamer world to the pre-streamer world, and complete red herring in sound quality terms.
I'm not sure this counts as an expansion on all of your points but hope it helps and I'm happy to have another pop!
Huge thanks again for your excellent post.
Nigel
Thanks for your well-considered post.
1. I absolutely agree. If one clock is lower noise than another clock, it absolutely can affect sound quality. I think we agree that this is nothing to do with clock accuracy. I have tried to be careful (but may have slipped up occasionally by using shorthand) to criticise claims that ethernet clock accuracy can impact sound quality rather than to criticise clock quietness.
2. Agreed. Noise causes no harm while it rattles around in the ethernet space. It doesn't even do any audible harm at the streamer itself, but the streamer's main job is of course to repackage the ethernet packets it receives into a bitstream which the DAC will recognise and in its turn convert to analog(ue). If we can stop noise reaching the streamer, we can make a major contribution to sound quality because it won't be forwarded to the DAC where RFI noise becomes audible through its impact on the analog(ue) componentry. Sure, we should also pay attention to how much noise gets from the streamer to the DAC and the right choice of cable here can also make a difference, but the focus of the thread is on the ethernet space.
3. Agreed (again!). I'd love to learn more about post-conversion-to-bitstream jitter for the benefit of my own audio systems if nothing else but I have much more to learn in this space before I can comment with any confidence. I enjoy living and learning...
4. On the manufacturer front, I guess my plea to fellow manufacturers in the ethernet space is that they take the time to really understand how asynchronous ethernet is completely different from synchronous post-streamer digital and not develop and market solutions to real problems in the ethernet space. As we know that the 7-layer OSI ethernet protocol will ensure the data (in our case representing music but the protocols really don't care) gets to its destination, the only variable influencing sound quality is RFI noise: it can be environmental, it can come down a wire, it can come across the ground plane... but in the network/ethernet space noise is all we can control.
5. I really do think that many manufacturers who promote the "issue" of clock accuracy in the pre-streamer domain are extrapolating inappropriately from the post-streamer domain, where we all know jitter is an audible thing and high accuracy clocks can have an audible impact. They need to be challenged to explain how ethernet clock accuracy can possibly affect sound quality when the data packets are transmitted asynchronously, subject to error-checking and if necessary retransmission, and ultimately converted to a completely different bitstream format by a device which has its own clock! I've seen some misleading "explanations" which talk about digital data not actually being 1s and 0s but being transmitted as an analogue waveform with curves and approximations and whatever: it's another completely erroneous extraploation from the post-streamer world to the pre-streamer world, and complete red herring in sound quality terms.
I'm not sure this counts as an expansion on all of your points but hope it helps and I'm happy to have another pop!
Huge thanks again for your excellent post.
Nigel
Last edited:
I have certainly observed, through listening, that an external clock for a switch, as well as an LPS for a switch, improve the sound but also contribute a sound (noise?) signature. That signature may or may not be what the consumer prefers in his setup and for his ears. How is the noise measured and the source(s) identified?
Similar threads
