Habanero Monk

Sounds like people are making this stuff harder than it is. What about USB audio is insufficient? What is 'Noisy' about it? Even $4K and $8-10K DAC's have USB inputs. Trust me guys like Emotiva, Bell Canto, Benchmark, Wyred, MyDAC etc have this figured out so you don't have to. Want to tweak a Windows machine? Turn off automatic updates Go into MSCONFIG and strip everything out by choosing the windows services options in the appropriate tabs. Don't install Java, Don't install Flash or simply turn off their update options. Both my HTPC and 2.0 music PC simply RUN. I don't browse the Internet on them. I don't even run Anti-virus/malware etc... My SQ is amazing. You are welcome to come on over.

Wireless, properly implemented, it the most isolating form of connectivity there is. I've read the thread and still unsure what problem is actually being solved.

If going through that extreme why not just get a regulated linear 125 watt ATX PSU built and use either the AMD Kavani or Intel Atom platforms. You could even plan on basing systems around POE v2 with it's 100 watt envelope. The power supply could literally be 328 feet away. An Atom 1900 based system all in with SSD/M-Sata would maybe draw 20-25 watts including the sound card.

USB not being routable, also being realtime does present problems. However distance limitations for many a home need not apply with USB Balluns that use CAT5 cabling to extend the run. I have one particular way to send out a configured box: I pre-assign a 172.16.xxx.xxx/24 address and the master computer that is used on the customer network is multi-homed NIC. Just point the customer to a 5 minute YouTube video to get it connected / self configured. Hardly ever get a call. On the occasional call it takes me about 3 minutes to tell them it's working and have a nice day. If I can't do it in 3 minutes I get to charge them for fixing their network!

Sounds like you are doing the HD Home Run but for audio. The unit acts as a bridge in this scenario. On one side sits the Antenna (source) and then it ties into the network. Computer finds it as a Media Center Tuner using a default class and Voila you have your Terrestrial broadcast packetized. Not sure what you guys are doing that Dante isn't or Crown or Meridian. Curious as to how you are going to supersede I2S (if I'm reading your post correctly). That would require custom sand I believe.

Even better and certainly 100% obtainable in homes: Wire less. Nothing to worry about at that point. The only thing that can remotely introduce sound is induced, external noise on the wire. If you have zero of that then a cable is a cable is a cable at that point. I had a September 27th date with a Polkie all setup but he declined at the two weeks prior. This was to see him compare his Belkin, another uber high end Ethernet cable of his, and my BJC certified Ethernet cables. I'll consider the 'Audiophile Ethernet Cable' foolishness put to rest as I can't get anyone to agree to the testing I took a decent amount of time and materials to setup.

Thanks for clarifying also thanks for pointing out the three shielding types: Float, tied to infrastructure chassis, and tied to both infrastructure and premise equipment. I just read it as there is timing variance / jitter in the Ethernet side of things that are contributing to it.

It's quite simple. Cisco, Shoretel etc all implement jitter buffers in the system. Usually adjustable up to a ceiling of 1500ms. The systems at this point aren't realtime but so quick we humans don't perceive it as non-realtime. I started with IP Telephony with the NBX product before 3COM purchased them. This was based on Wind River VX RTOS and worked well over Frame Relay. This was the early days of SIP trunking and believe it or not toll trunk by-passing was ILLEGAL. Let me know what other questions you have.

This is easily testable. Set up a large buffer. Enough to hold an entire track or series of tracks, start the play, let 30 seconds pass by for the buffer to fill. Then see if participants can hear when the cable is and when the cable isn't physically connected. My favorite remedy is going wireless. Setup a dedicated Music only Access Point. Get's it's own SSID and channel. Wire it right in the room with the playback computer.

I don't think your understanding on this is complete. Jitter that exists on the Ethernet side can't show up on the re-clocking side of the DAC. Only missing data is of issue here. That is data that has missed the data transmission window and doesn't get retransmitted before buffer under run. The reason why is that Ethernet is 100% not a realtime mechanism. It fills a buffer and then the playback application pulls data out of the buffer. When the buffer hits a certain point a request is made and it's filled back up. Technically, and I have proven this, you can pull the Ethernet cable and the audio will still play. Also Ethernet connections are transformer coupled / galvonically isolated mechanisms. I have a few TI papers on this. While the article you linked to is great, the Author isn't speaking about Ethernet data.

If we are filtering for electrical properties I would just rather put in a dedicated Wireless Access Point that just serves my streaming needs. No cable to filter and since the WAP is, well, wireless, no LCR to worry about.

If using a 3rd party media player on a computer did you start playback, then pause, remove the cable, and then start playback? Did the sound change with the cable removed? Sounds like you have some serious EMI/RFI going on. What could be the contributors and do you think you would better off fixing the cause vs a bandaid with cable? If an ethernet cable is letting in some noise is it only there when transmitting or any time the cable is connected? Packet based audio is hurry up and wait. The application will take just a few milliseconds and fill up the buffer and then wait. Remember the computer isn't playing from the ethernet cable. It's playing from buffer.

If you have setup Cisco for VOIP then you should have bumped into their jitter buffer setting. If I recall you can set it for up to 1500ms of buffer.

No Ethernet doesn't need 'purified'. Try this: Install JRiver. Adjust it's prebuffer from it's default 6 seconds to 20 seconds. Start playing your file. Wait 3 seconds and pause your playback. Pull your Ethernet cable or disconnect from your wifi network. Press play and let me know if you are playing from buffer or from your Ethernet cable. Ethernet and up stream application error checking and correction will have made sure that the data is error free.

They would have displayed screenshots from a real scope.... Not some cartoonist illustration.