https://www.dxengineering.com/parts/dxe-iso-plus-2
Anyone tried these in their setup? At least the price seems reasonable.
https://www.dxengineering.com/parts/dxe-iso-plus-2
Anyone tried these in their setup? At least the price seems reasonable.
Yet more snake oil. Honestly, people need to just walk away from this â â â â â
Reminds me of ââŚthe laws of physics continue to work whether you believe in them or notâŚâ .
Yes, the DXE filters are relatively cheap but, No, they did not make a positive audible difference in my setup. I use a Meridian 218 and a Allo USBridge Signature as endpoints for network-to-SPDIF.
Then you should remove the EtherRegen! If the way AFTER the EtherRegen makes a big improvement over the thousands of kilometers of cheap cables from the Tidal/Quobuz server the only cause can be that the EtherRegen has a negativ impact and so should be removed from the chain.
Please donât be stupidâŚI came with optic fiber to ER and to streamer with copper.
I never understood why after a question all kind of people who have no clue nor inversted in a high res system keep fighting back for stuff donât understand?
I need advise only from people who really understand what means a network integration regarding audio signal and already tried options.
You got a lot of advice from people who REALLY understand network integration. If you would listen you had understood that the âregarding audio signalâ aspect is what the snake oil dealers are promoting. It is only data before it arrives at the DAC, not different from this text in the forum and donât need a different treatment.
Maybe you know the saying, âWhen you point one finger, there are three fingers pointing back to you.â
There is a big difference between âtext in the forumâ (or Word or similar) and streaming:
BradâŚI may have started the s-storm last year when I innocuously reached out for subjective listening impressions from folks who have tried the ENO filter. Quite simply, I was curious to see if any other observations, pro or con, aligned with my personal experience. The shaming from readers of this forum you refer to was fast & furious! Measurements donât always tell the entire story when it comes to this wonderful hobby. I could care less about the opinions of skeptics who have not personally tried the various products they are so quickly to criticize. Ultimately, itâs how it sounds to the individual. This is why so many companies offer 30, and in some cases, 60 day trial periods. If you like the improvements the ENO has made to your streaming system, give the Network Acoustics MUON filter a try. I found it builds on the attributes of the ENO like a more natural, relaxed presentation that reveals even more of the music especially at lower volume levels.
Ok
Time for tempers to cool here as well.
Thank you for your patience and understanding
OK guys both this and Power cables are now compromised. Letâs move to hi-rez-foolishnes
It was mention many times in this thread: this is right if a protocoll like udp is used, but not with tcp/ip. Jitter is not possible with tcp/ip and packet delay variations are leading to dropouts if big enough and nothing else.
It feels like groundhog day. Same arguments again and again, no matter how many times they have been disproved. Very sad
You mention audio/video streaming again, however, as was discussed yesterday it is only relevant in real-time protocols such as VOIP/UDP. Where streamed audio is concerned, especially Roon which uses RAAT (Roon Advanced Audio Transport) which is TCP/IP based, jitter and packet delay variation are irrelevant. TCP/IP either works or it doesnât. The data either gets there 100% intact or it doesnât. There is no in between. If the data doesnât get there, you get dropouts, pauses, silence. You donât get reduced sound quality if there are timing issues with TCP/IP.
Audio data is low bandwidth - I can successfully stream hi-res from Qobuz most of the time in the car from my Android smartphone. If the datastrean is too slow, I get silence.
Any competent home network should have no issues with streaming audio. There is no need for any other Snake-Oil products aimed at improving âjitterâ or timing or noise or any other invented audiophile voodoo sh!t.
Just to be clear and fair:
You wrote that where streamed audio over TCP/IP is concerned, jitter and packet delay variation are irrelevant. Would you please provide me with a link to technical documentation on this topic (if possible, then one for dummies)?
The part with âaudio data is low bandwidthâ is already clear / familiar to me.
If they were relevant, all digital data transmissions would be affected, not only audio. I think itâs been said enough times already: there is absolutely nothing special about audio data.
Hopefully the following simple articles will give some more insight.
TCP/IP is time insensitive. It doesnât matter in which order packets are received as the protocol ensures that no matter which order packets are received, the receiving device sorts the packets into the correct order. Any missing or damaged packets are resent.
Think of ordering a jigsaw puzzle via the mail - (hopefully) all of the pieces arrive, the picture on the box lets you see what the finished puzzle looks like. It doesnât matter in which order you assemble them as the finished puzzle will be the same. If any pieces are missing, you contact the supplier and he sends you the missing pieces or a new puzzle.
Provided the data stream doesnât utilise too great a proportion of the network bandwidth available, thereâs plenty of time for missing/damaged packets to be requested and re-sent.
As we discussed earlier, the bandwidth requirement for audio is very small - even DSD512 only utilises just under 50Mbps, so even 100BASE-T should handle it.
https://www.cloudflare.com/en-gb/learning/ddos/glossary/tcp-ip/
UDP is very different. Think of building a jigsaw puzzle starting at the top left and building it downwards line by line in the way a book is read. Someone is throwing the pieces to you across the room in the order they need to fit the puzzle. You have to catch a piece and fit it to the puzzle before the next piece is thrown. You can only hold one piece at a time. If youâre too slow, either you wonât have time to put a piece in place or you wonât be able to catch the next one. The result will be a finished puzzle with pieces missing.
https://www.cloudflare.com/learning/ddos/glossary/user-datagram-protocol-udp/
Could you specify the issue?
You really did watch the video of Hans? There he clearly outlines that jitter etc. doesnât have any effect on the data transmission (otherwise TCP/IP and the IT industry wouldnât work), rather then on analog to digital and digital to analog conversion.
The first is done in the studio. The second
(See again in section âBits are bitsâ) has an impact when listening to music.
Hopefully this is finally clear to anyone and we can go on from there
Thank you for your answer and clarification.
You provided me with exactly the kind of information I needed.