Jump to content
IGNORED

Wavelength Ethernet Spacelator


Recommended Posts

22 minutes ago, plissken said:

 

Well I know what I've measured and Wired or WiFi has no audible effect on the output of my Emotiva DC-1.

 

Using 1Khz input nothing but a bit of mains noise way beyond perceptible hearing and that went away with both optical and WiFi.

 

I don't know everything but I do know some things.

 

It doesn't because if it did you would have posted something crowing about it.

 

If the non-linearities propagated down into the human hearing band you would have posted a resource on it.

 

Actually the more they can market without any peer review the better.  They will let the gullible with gold ears do the selling.

 

Wifi is downright reliable actually. I have 248GB wireshark capture with 0 dropped packets and only 4 re-transmits around here somewhere.

 

Heck, you can pickup Cisco 2960-8-TC's left and right for $25 with SFP GB. That will provide every ounce of isolation.

 

 

 I've moved on to powerline Ethernet.  Wifi  is too variable. Gb powerline works great between my server in the kitchen and renderer setup in the garage, plenty of bandwidth,

no mysterious pauses.

Regards,

Dave

 

Audio system

Link to comment
1 minute ago, jabbr said:

Don't make assumptions, and don't twist what I have already posted, including references. My own interests lie more in DAC and amplifier topologies. where certain nonlinearities are clearly audible ...

 

Again, you need to show that 25Mhz non-lineartities due to phase noise or signal driving, propagate into the human audible band.

 

There's a ton of research out there. Surely you can provide something to backup your hunch.

 

I've put my DAC on a and ACD and running True RTA haven't seen anything except some mains noise about 30db down beyond human hearing.

 

Link to comment
1 minute ago, davide256 said:

 I've moved on to powerline Ethernet.  Wifi  is too variable. Gb powerline works great between my server in the kitchen and renderer setup in the garage, plenty of bandwidth,

no mysterious pauses.

 

I've found that it's not WiFi that's the problem. It's the implementation. There are plenty of other solutions as you have found.

 

For $100 I have WiFi that gives me a consistent 38MB a second with sub 3ms SRTT.

Link to comment
Just now, plissken said:

 

I've found that it's not WiFi that's the problem. It's the implementation. There are plenty of other solutions as you have found.

 

For $100 I have WiFi that gives me a consistent 38MB a second with sub 3ms SRTT.

mmm, implementation, by that do you mean the router application layer handling multiple wifi connections? Because that's what seems foobar to me.

Regards,

Dave

 

Audio system

Link to comment
2 hours ago, davide256 said:

mmm, implementation, by that do you mean the router application layer handling multiple wifi connections? Because that's what seems foobar to me.

 

Wifi would be at the Physical-Data Link Layer, not application.

 

What I did in my scenario is a dedicated $65 WiFi MIMO router setup for AP only, on it's own channel  and SSID.  Spent another $35 on a good WiFi PCIe card.

 

Did a capture of 248GB of streamed audio in WireShark and 0 dropped packets. I'm not sure how that can be improved upon and I think it's certainly repeatable. If you are in dense apartment complex I could see some issues. The only thing you can do then is find a least congested channel and allow CDMA back off routine sort everything out. Or run wired.

Link to comment
49 minutes ago, Ralf11 said:

powerline Ethernet seems like a huge noise problem - how much effort has gone into getting noise out of the mains?

Agreed on that one..Powerline ETH is a disaster in terms of noise. Just tune into your favorite AM Radio station via a small hand held and walk around the room to hear the results of your efforts after implementing powerline ETH ?

 

On the topic of these various ETH "doodads" that refer to "Re-Clocking" ETH signals.  Are these devices with the special Clocks dependent on the TCP Header data in anyway in order to perform their Clocking/Re-Clocking?

 

If so, what would be the reason for a ROON User to purchase one of these devices since ROON uses UDP with only basic Header info available? ?

Link to comment
1 hour ago, cjf said:

On the topic of these various ETH "doodads" that refer to "Re-Clocking" ETH signals.  Are these devices with the special Clocks dependent on the TCP Header data in anyway in order to perform their Clocking/Re-Clocking?

 

Every Ethernet switch reclocks the Ethernet signal. It does not depend on the TCP header.

Custom room treatments for headphone users.

Link to comment
13 hours ago, cjf said:

Agreed on that one..Powerline ETH is a disaster in terms of noise. Just tune into your favorite AM Radio station via a small hand held and walk around the room to hear the results of your efforts after implementing powerline ETH ?

 

On the topic of these various ETH "doodads" that refer to "Re-Clocking" ETH signals.  Are these devices with the special Clocks dependent on the TCP Header data in anyway in order to perform their Clocking/Re-Clocking?

 

If so, what would be the reason for a ROON User to purchase one of these devices since ROON uses UDP with only basic Header info available? ?

 

One use of power line Ethernet would be to deploy a WAP in proximity to the streamer.

Link to comment
13 hours ago, cjf said:

On the topic of these various ETH "doodads" that refer to "Re-Clocking" ETH signals.  Are these devices with the special Clocks dependent on the TCP Header data in anyway in order to perform their Clocking/Re-Clocking?

 

Those are all (that I know of) low level Ethernet devices and don't understand higher OSI layers like IP and even less TCP/UDP.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

I see, so these ETH devices being discussed are strictly attempting to operate and "work there magic" within the Physical Layer 1 realm of the switch hardware? 

 

Assuming the above is true, I wonder if we are peeking into the "Asynchronous Serial Communication" world (ie..both ends of the link dont not share a common clock source)? At least to me it seems that Clocking/Re-Clocking is the main talking point of these special audiophile ETH devices so far.

 

I've never really had a need to dive deep into the physical layer of switches before but I am curious now.

 

I wonder how Clocking/Re-Clocking in an Asynchronous manor on one switch in the network chain could possibly affect what happens to the SQ at the receiving end (ie..streamer/Dac) since whatever magic was done at the audiophile switch has no transport or header space reserved for it within the Ethernet Datalink Frame so it would be unable to communicate the "fixes" that it felt were necessary to the other end of the link. This all assumes we are only talking about "dumb" Layer 2 switches that is.

 

Lastly, I wonder how the FCS (Frame Check Sequence) Header plays into this which is found within the DataLink Ethernet Frame (ie..OSI Layer 2). The FCS is calculated using an already known formula (if I remember correctly) so both ends of the link can use that formula to check if errors/changes occurred in transit. If there were changes (maybe by the audiophile switch?) and the formula doesn't return the correct answer the frame is discarded.

 

Hrrrrmm..the rabbit hole is very deep on this one. I'll sit back and watch with interest for now but must say I am a bit skeptical at the moment what additional value these devices will bring to the table ? 

Link to comment

At least my streaming protocols operate at UDP/TCP level and doesn't really care what kind of physical link is underneath and doesn't distribute any clock. Thats why it works over Ethernet, WiFi, powerline, etc whatever that can carry TCP/IP.

 

Same goes also for other protocols like UPnP AV.

 

There are some protocols that rely more on the lower levels, namely AVB. And AES67/Dante/Ravenna to lesser extent. Former I haven't seen being used for audiophile cases, while Ravenna is used to some extent. But still, these rely on PTPv2 protocol for clock distribution and feed it to a DPLL for clock generation.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
On 11/12/2018 at 4:18 PM, Miska said:

There are some protocols that rely more on the lower levels, namely AVB. And AES67/Dante/Ravenna to lesser extent. Former I haven't seen being used for audiophile cases, while Ravenna is used to some extent. But still, these rely on PTPv2 protocol for clock distribution and feed it to a DPLL for clock generation.

 

Protocols like SIP and MPLS, engines like CEF/FIB all work at the L2/L3 boundary.

 

In the case of CEF it's quicker to establish a L2 path and forward frames to the next hop mac where speed and time are application critical.

 

Thank goodness pre-recorded audio isn't that ?

Link to comment
10 hours ago, davide256 said:

there are far nastier things adding noise to your mains. Or do you turn off your HVAC, refrigerators  and motorized equipment when you listen?

Why does powerline communication have an exemption from EMC rules, why did EMC UK (Keith Armstrong among others) try and get it banned....

Link to comment
On 11/12/2018 at 12:51 AM, cjf said:

If so, what would be the reason for a ROON User to purchase one of these devices since ROON uses UDP with only basic Header info available? ?

 

Not that it perhaps matter but Roon switched from UDP to TCP in build 234.

 

Today’s release of the core includes a re-design of RAAT’s audio streaming protocol that uses TCP instead of UDP to transmit the audio stream.

Main system
TAD D1000mk2, TAD M2500mk2, TAD CE-1, Ansuz Mainz 8 C2, Ansuz Darkz D-TC, 
Qobuz Studio -> Roon ROCK on NUC -> Uptone etherREGEN -> dCS Network Bridge -> AES/EBU -> DAC
HD Plex 200W PSU (4 rail for ISP fiber, router, etherREGEN and NUC)
 
Second system
Qobuz Studio -> Devialet Silver Phantom, Devialet Tree
Link to comment
34 minutes ago, marce said:

Why does powerline communication have an exemption from EMC rules, why did EMC UK (Keith Armstrong among others) try and get it banned....

 

At least here also the power consumption meters communicate back to the power company using powerline data transfers.... This is why I can see realtime power consumption data of our house from the power company's web pages.

 

No, I'm not as such using or recommending power line Ethernet as primary option, but I think it is viable alternative. I personally just don't need it because the entire house is wired with CAT6 and in addition I have 802.11ac wireless with multiple access points (corporate models) around the house.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
5 hours ago, marce said:

Why does powerline communication have an exemption from EMC rules, why did EMC UK (Keith Armstrong among others) try and get it banned....

sounds like a commercial turf battle to me. But what do I know, I'm only a 20 year Internet veteran of the corporate gaming that goes on with advisory bodies,

 

" It can also interfere with the delivery of broadband Internet by xDSL technologies using telephone cables, slowing their data rate " is where I smell political

corruption. 

 

Just don't use it if you have xDsl or if you are a shortwave ham radio operator.

 

Regards,

Dave

 

Audio system

Link to comment
3 hours ago, marce said:

PLT, power line communication is adding EMC to the mains, so you distribute it everywhere, it can couple all over the place and filtering it is not as easy as some presume…

A lot of you get excited about a few pA of noise from a SMPS, yet will quite happily add far more noise to the mains using PLT, it is a bit of a joke…

Anyway if you want to get a broader view of the problem here is some info from EMCIA:

https://www.ban-plt.org.uk/emcia.php

 

Well said!

 

Need to keep everything in perspective!

 

I've used PLT in the past, never been too impressed, and WiFi has progressed to the point where mesh networks are very fast.

Custom room treatments for headphone users.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...