Jump to content

Recommended Posts

1 hour ago, recur said:

John, I'm just a tad experienced in networking and have decades of experience delivering far more time sensitive and bandwidth heavy applications than audio

I do not doubt for one moment the extent of your networking skills, knowledge and experience.  As I said of myself and others, we are not so blessed. 

I seem to remember some time ago that @rmpfyf  suggested to me to try and change a switch to 100 Mbs instead of 1gb as there maybe a benefit.  With the switch that I had it wasn't possible to change it.

This morning I disconnected my audio switches and replaced them with a just a Netgear 108 with an ordinary smps.  I kept the cables in as it was too complicated to remove those.  Played something that I use for comparison purposes.  The result was good as I had expected it would be.  Put the audio switches back with no other changes at all.  Result was better with more life and decay. 

John

Link to post
Share on other sites
  • Replies 239
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

There's always going to be a little friction in these discussions because people who actually do networks (and other IT) for a living deal in hard reality and not wishy thinking.   Networks

@rmpfyf I’ve lost interest in discussions about Ethernet, cables, switches and routers around here.  Please leave me out.   There are way too many people on here with a deep seated belief that

John, I'm just a tad experienced in networking and have decades of experience delivering far more time sensitive and bandwidth heavy applications than audio.   I've been involved in design a

5 minutes ago, Ittaku said:

I'm a Japanese translator... I explained it above.

You explained the name of the product, but their own site (and reseller sites) specifically call the USB part a hub, and the Ethernet part a hub. So the whole things is a SmartHub, but it contains separate USB and Ethernet hubs.

Link to post
Share on other sites

There's always going to be a little friction in these discussions because people who actually do networks (and other IT) for a living deal in hard reality and not wishy thinking.

 

Networks are observed in terms of bandwidth and latency and packet loss and CRC errors and other measurable, real world, concrete details. Performance problems are measured in terms of "the database is I/O bound because the interfaces to the NFS head are running hot" or "packet loss is killing the connection between the firewall and the load balancers, I better go fix that". Or a hundred and one other problems.

 

Network switches, for the most part, either work or they're faulty. There's no shining improvement by putting fancy clocks on them, because if they were clocking out frames at the wrong rate the next device would just discard the frames and hopefully count the CRC errors or even isolate the jabbering device. 

 

We know that despite what Audioquest might claim in between describing hard drives as a "record player" with "surface noise", ethernet frames are not like I2S with a bitstream that can suffer from jitter and latency. The switches have memory and store 'n' forward. Routers have queues. NICs have buffers which are copied to memory which are unpacked and copied to memory and so on and so on. Geez, now everything is increasingly https, you've got so many more memory copies for decryption.

 

So any time the idea of a thousand dollar ethernet cable or an audiophile switch with clever clocks and magical properties comes up, the response is pretty much like an oncologist hearing that a patient is going to treat their cancer with homeopathy -- there's an instinct to offer advice, to suggest that's not the right course of action; to scream quietly. And when we read that people "hear more air" or "more PRaT" or "warmer presentation" from switching ethernet gear around, we're going to say confirmation bias because unless we're going to accept paranormal outcomes, it just doesn't work that way. And there's a bit of a drive to push back against the companies selling this stuff for the same reason that oncologists push back against quack cures for cancer -- we don't like seeing people taken advantage of. 

  • Like 4
  • Love 3
Link to post
Share on other sites


58 minutes ago, pwstereo said:

You explained the name of the product, but their own site (and reseller sites) specifically call the USB part a hub, and the Ethernet part a hub. So the whole things is a SmartHub, but it contains separate USB and Ethernet hubs.

Nations that use English as their second language infamously misuse English terminology either completely or - far more commonly - miss the nuance. If the title and description ends up using these loan words, then unless they have a completely renamed product for the English speaking world, it will propagate. Getting hung up about it is pointless. The question was whether it was a network switch or not and it is, and to them it's a "networking hub".

Link to post
Share on other sites
2 hours ago, recur said:

I continue to love the furphy that abounds that a 100 Mbps port is better than a gigabit port because "noise". 

 

No, it's a timing source used to generate a periodic output offers inherently better timing accuracy at lower generated frequencies - simple maths. Not a noise thing. This sounds crazy to a network person as the effect in packet networks is indirect, the usual 25MHz crystal exists to run the board and the effect on packet periodicity is limited. Packet network exist so that it can be a 2c crystal not a precision OCXO and transmission still works. If you want to force timing, use PTP.

 

2 hours ago, Assisi said:

It seems to me that you and a few others are taking a simplistic perspective to what is possibly a little more complex for many of us.

 

Some members of Stereo Net have the knowledge and skills to design and construct well performing audio components.  Most members are probably not so blessed.  Most need to buy what they need or want.  Even less members probably have the knowledge and skills to put together and setup networks with the components as discussed in this and other threads.  I have to buy the components and connect them up and hope that the network actually works.  I am still surprised that mine does and especially the listening outcome. 

 

In simple terms what is the problem that can be easily solved?  How would a person with no network skills go about doing it?

 

It's simple, and I've mentioned it before. 

  • You can reduce conducted noise >> simplistic perspective is a transmission methods developed to be immune (fibre, used in high-noise environments)
  • You can reduce the amount of traffic >> simplistic perspective is to sub net it, VLAN, etc
  • You can make the periodicity of communications more regular >> simplistic approach is to force timing through a standard that allows a master clock source, and is engineered to compute time lag throughout network components (AES67 using PTP and IEEE 1588, which are common in industrial automation - note this is very different to bandwidth arguments)

 

The audiophile industry has directly or indirectly observed these challenges and done differently:

  • You can reduce conducted noise >> go long trying to make a copper cable act like fibre, all sorts of (fibre!) isolators, absorption in the box, cascaded switches (more iron isolation) etc
  • You can reduce the amount of traffic >> cascaded switches (depending how they're managed)
  • You can make the periodicity of communications more regular >> switches with better regulated clock sources though having no direct effect on packet periodicity (there is an indirect effect), expensive cabling with very high conductivity enough to better preserve waveforms, rising edges, etc (which very often is longer than is ideal for the application)

 

Now, whilst the solutions are conceptually simple actual diffusion in the market is hard. I had a good post here on page 1.

Link to post
Share on other sites
1 hour ago, PCOWandre said:

There's always going to be a little friction in these discussions because people who actually do networks (and other IT) for a living deal in hard reality and not wishy thinking.

 

Networks are observed in terms of bandwidth and latency and packet loss and CRC errors and other measurable, real world, concrete details. Performance problems are measured in terms of "the database is I/O bound because the interfaces to the NFS head are running hot" or "packet loss is killing the connection between the firewall and the load balancers, I better go fix that". Or a hundred and one other problems.

 

Network switches, for the most part, either work or they're faulty. There's no shining improvement by putting fancy clocks on them, because if they were clocking out frames at the wrong rate the next device would just discard the frames and hopefully count the CRC errors or even isolate the jabbering device. 

 

We know that despite what Audioquest might claim in between describing hard drives as a "record player" with "surface noise", ethernet frames are not like I2S with a bitstream that can suffer from jitter and latency. The switches have memory and store 'n' forward. Routers have queues. NICs have buffers which are copied to memory which are unpacked and copied to memory and so on and so on. Geez, now everything is increasingly https, you've got so many more memory copies for decryption.

 

So any time the idea of a thousand dollar ethernet cable or an audiophile switch with clever clocks and magical properties comes up, the response is pretty much like an oncologist hearing that a patient is going to treat their cancer with homeopathy -- there's an instinct to offer advice, to suggest that's not the right course of action; to scream quietly. And when we read that people "hear more air" or "more PRaT" or "warmer presentation" from switching ethernet gear around, we're going to say confirmation bias because unless we're going to accept paranormal outcomes, it just doesn't work that way. And there's a bit of a drive to push back against the companies selling this stuff for the same reason that oncologists push back against quack cures for cancer -- we don't like seeing people taken advantage of. 

I completely understand where you are coming from on this.
 

If there was an explanation of why networks can affect the SQ of streamed music, would that change your perspective?  The best explanation of why network switches / routers and isolators affect audio SQ is here:UpTone-J.Swenson_EtherREGEN_white_paper. 

 

It is, to my mind a very clear and persuasive argument for what I hear.  However, I am not knowledgeable enough in networking to know if it is factually incorrect.

Link to post
Share on other sites
1 hour ago, pwstereo said:

What does decay mean in this context

The note hangs or last longer in the air and you move into a silent space for a moment.  It may be simply because there is a reduction in noise floor that may mask the delicate end of the note and the silent space.  All the audio switch may do, is reduce or remove interference or noise in the signal that you would otherwise hear.

 

 

With the virtually nothing that I know about networks and Ethernet, I am sure that the those who say it is all about the integrity of 1s and 0s being sent and received correctly is absolutely correct.  What I sure about though, is that there is something else that happens and is important with audio switches and cables.  The numerous gear that the network people refer to may be mission perfect for what it is designed for. 

 

 

Is it designed to remove interference/resonance that can pollute and spoil the audio signal?  If there is interference/resonance inherent in the referred to gear, is that critical to the performance of their networks?

 

 

Some people do not appreciate how noise floor can spoil what you are listening to.  When I first experienced a reduction in noise floor, initially I did not know at the time what had happened.  The minimisation of interference/resonance can be an expensive pursuit.  I have been pursuing the reduction in noise floor in every way ever since my first realisation to enhance my listening pleasure.

 

John

 

Edited by Assisi
Link to post
Share on other sites


2 minutes ago, Stereophilus said:

It is, to my mind a very clear and persuasive argument for what I hear.  However, I am not knowledgeable enough in networking to know if it is factually incorrect.

It's pretty much voodoo wishy thinking, on the face of it. I'll give it proper re-read later, but the facts just aren't stacking up. If ethernet frames were a primary cause of "ground plane noise", the problems wouldn't be restricted to audio, you'd have bright flashes on screens and generally the whole thing would lock up because the timing for accessing memory (RAM) is thousands of times more strict than S/PDIF or USB audio.

 

Also, there's actual test equipment that can measure the quality of ethernet timing, and nobody selling "clever solutions" seems to have actually used it, nor have they ever had an independent third party assess it. If the timing of ethernet frames could have any audible impact, the first call to action would be to eliminate as many frames as possible. You'd be surprised how much broadcast traffic is on the average home network. 

 

That's a well-written bit for justifying the story, in the same way that Shakti have some pleasant to read bits around their "stones". However, despite their promise that they can increase engine performance and fuel economy in these times of increasing emissions standards, no car manufacturer has filled their engine bay with Shakti Stones because while the story sounds plausable prima facie, there's just no substance to it.

Link to post
Share on other sites
11 minutes ago, Assisi said:

The note hangs or last longer in the air and you move into a silent space for a moment.

Thank you for explaining.

Link to post
Share on other sites
8 minutes ago, Assisi said:

have been pursuing the reduction in noise floor in every way ever since my first realisation to enhance my listening pleasure.

Reduction is noise floor is measurable, though. Very simple. Play a zero-bit track of silence with the volume wound up to 100% and measure the noise. Then swap gear in and out and take more measurements. If plugging in an ethernet cable increases the noise, there's a problem that can be fixed. This is why I've stated a few times that the one thing I can buy is using isolation in some cases where noise is a demonstrable problem, although killing the source of the noise always seems smarter than covering it up. 

  • Like 1
Link to post
Share on other sites

Interesting discussion although being an IT guy who has done his share of networking I think I'd fall on the side of skeptical when it comes to claims of being able to affect the quality of audio playback using a different ethernet cable.

 

However, one thing that got dropped earlier in the conversation was the use of mesh networks in your home to get around Wifi transmission issues.  I can only wholeheartedly recommend that you throw away anything you are currently using in a bigger house for Wifi if you haven't got a mesh network.

 

We bought the Google Wifi stuff when it came out (3 pucks) and I stopped running ethernet through my house after that.  I am lead to understand the newer Nest product is even better.  I still have an ethernet switch with the A/V gear in the lounge to get rid of any NAS traffic and to help with a Fetch box, but everything else is going over the mesh Wifi and it's incredible compared to trying to use those stupid repeaters that halve your network speed.

 

This house is loooooong too, just put the  pucks in three different spots (one in the lounge/dining at the front of the house, one in the middle and one in the back in the study.  Can't recommend them highly enough.

  • Like 1
Link to post
Share on other sites


Hmm.. interesting thread. 

 

Question, say a digital file containing bytes of information, gets moved from server A to B and than to C and than to D and so on. Does that byte of the information within that digital file changes after all these move?

Link to post
Share on other sites
1 minute ago, :) Go Away (: said:

Question, say a digital file containing bytes of information, gets moved from server A to B and than to C and than to D and so on. Does that byte of the information within that digital file changes after all these move?

Not unless something is very seriously wrong. And we demonstrate this (and check for it manually in some cases) using tools like MD5 signatures.

  • Like 1
Link to post
Share on other sites
42 minutes ago, Old Man Rubber said:

Interesting discussion although being an IT guy who has done his share of networking I think I'd fall on the side of skeptical when it comes to claims of being able to affect the quality of audio playback using a different ethernet cable.

 

However, one thing that got dropped earlier in the conversation was the use of mesh networks in your home to get around Wifi transmission issues.  I can only wholeheartedly recommend that you throw away anything you are currently using in a bigger house for Wifi if you haven't got a mesh network.

 

We bought the Google Wifi stuff when it came out (3 pucks) and I stopped running ethernet through my house after that.  I am lead to understand the newer Nest product is even better.  I still have an ethernet switch with the A/V gear in the lounge to get rid of any NAS traffic and to help with a Fetch box, but everything else is going over the mesh Wifi and it's incredible compared to trying to use those stupid repeaters that halve your network speed.

 

This house is loooooong too, just put the  pucks in three different spots (one in the lounge/dining at the front of the house, one in the middle and one in the back in the study.  Can't recommend them highly enough.

Thanks, although that goes completely against opinion earlier in this thread... back to the drawing board.

Link to post
Share on other sites

Well, there has been a lot of discussion.  There is too many specific comments I am tempted to reply to.

 

As I imagined again there is 2 camps.

 

We could continue debate which camp is more correct, however it is likely both are, and also very likely there are people much more expert and experienced than us in this weird little niche of networking.

 

To my ears, in my system, there is definitely things in networking that change sound quality.  My aim is to discover practical ways to put together a network to yeild best sound quality with devices etc that the average person can use.

 

I am willing to invite people that are skeptical to hear the difference it makes in my system.

 

So, can I suggest we try to respect our beleifs, differences and values and harness our collective knowledge to bravely explore possibilities.

 

As you may know, I have created threads about ethernet cabling, switches and tweaks for discussion on those things.

 

So getting back to the topic of this thread, its not clear ro me if  @rmpfyf or anyone else provided a clear answer to my query which was along the lines of, what would be better than MikroTik?

 

I am not particularly seeking in a lengthy technical explanation (although happy to read them even though alot of it goes over my head). And I honestly dont care if its 'audiophile' or not if it performs in a way to improve sound quality.  I would gladly like to find a lower cost solution and not be conned by hype.

 

In the back of my mind, I suspect there are some products which despite marketting may not perform better than 'industry standards'.  However it would take a gutsy commitment to invest in production of audiophile products that are not value for money compared to industry standards ... knowing there is a world full of skeptics ready to highlight better performing solutiions at lower cost.

 

Finally, while I have my own personal interests in this info, it also benefits people who read but dont participate in discussion. And my experience with trials will also be shared and ideally verified by others (based on their systems, or hearing mine) to contribute to our collective knowledge.

 

Dale

Link to post
Share on other sites


1 hour ago, PCOWandre said:

It's pretty much voodoo wishy thinking, on the face of it. I'll give it proper re-read later, but the facts just aren't stacking up. If ethernet frames were a primary cause of "ground plane noise", the problems wouldn't be restricted to audio, you'd have bright flashes on screens and generally the whole thing would lock up because the timing for accessing memory (RAM) is thousands of times more strict than S/PDIF or USB audio.

I’m just going to ignore the bit about Shakti stones, as I don’t think it’s relevant to an intellectual discussion.

 

The way I read it, the author is justifying his position by suggesting upstream components of a DAC (talking specifically here about a device that is highly sensitive to timing errors) can influence the ground plane voltage and therefore threshold voltage for the DAC.  I think the video analogy is appropriate, as a video processing chip would process the same timing errors as colour variations in an individual pixel for fractions of a second.  1 pixel a bit darker or a bit lighter is probably not detectable all that easily for most of us and there is ignored for the most part.  The claim in the article is that these small timing variations affecting a DAC are audible.

 

The argument about integrity of data transferred , buffered or stored are not part of the argument, as he is suggesting the variations occur at the DAC.

Link to post
Share on other sites
32 minutes ago, PCOWandre said:

Not unless something is very seriously wrong. And we demonstrate this (and check for it manually in some cases) using tools like MD5 signatures.

This pretty much summarises how the digital domain works. Cables makes the data transfer faster or slower, but does not alter the digital file. If it did, I am sure, I wouldn't mind seeing my bank balance being distorted and having few zeroes in back added.

 

What I mean to say, is that the digital bytes that forms the audio stream/file does not change at all by changing the cables or CPU or RAM. By changing the cables or switches what it would impact is how fast that file can be presented from point A to point B and thats it. 

 

Yes, cables, routers and switches does make difference on how the data is being transferred, but in no way it changes the data. Yes, we often change the fibre cables or DAC cables between switches or server as it causes multiple errors in data transfer and changing the cables often resolves this.

 

It is lot like, playing a very large video file on a media player over wifi network vs playing it locally on that same media player. The video file does not change, but playing it over wifi can cause few skips and pauses as it has to buffer enough data in order to play the next content vs playing it locally has a smooth playback. File remains same, but the playback changes by changing the method of transfer. 

 

One would rather benefit by improving the overall network to say from 100mb to 1000mb network. But changing the cables within same network most likely will not result in any improvement other than some latency errors being improved.

 

As for the suggestion on equipment.

Some standard switches: https://www.fs.com/au/products/90130.html or something higher on chain, https://www.fs.com/au/products/90132.html

DAC cables: https://www.fs.com/au/products/48884.html

Fibre cables: https://www.fs.com/au/products/40192.html

Cat8 RJ45: https://www.fs.com/au/products/72756.html

 

Edited by :) Go Away (:
Updated link.
Link to post
Share on other sites
12 minutes ago, PCOWandre said:

Not unless something is very seriously wrong. And we demonstrate this (and check for it manually in some cases) using tools like MD5 signatures.

Absolutely. Networking depends on being able to guarantee payload integrity from end to end. If it didn't work, you wouldn't / couldn't do internet banking on it. 

 

The real crux of matters is, networking was designed and iterated to death to fix real problems (latency, packet loss etc) and has evolved to be overwhelmingly awesome at creating a super high performance mechanism of sharing digital data precisely  and optimally between two endpoints. The underlying protocols from the physical layer up the stack to the application layer all have their own performance optimisation and inherent fault checking mechanisms to make sure if something goes bad in transmission, that the bad bit of data gets sent again.

 

Most of the physical layer issues in the analog audio world, are mitigated and even negated through cabling choices, link layer protocols, network layer protocols, transmission protocols and then an application that sits on top of it all which can elect to do it's own end to end payload verification.  This means we've built a highly resilient transmission technology that abstracts away things like noise that are a problem in analog audio to something that is overcome with judicious use of many layers of technology mechanisms.

 

We know that the payload that you get is bit perfect. If it's not, we get to see at multiple parts of the transmission stream where the error exists and depending on the identified location, you can then fix at your leisure (new cables, new physical interfaces, new computer... select your poison).  TCP knows a bad packet has arrived due to checksums and will ask for a replacement if this happens. 

 

Best of all, we can see these statistics in real time on a proper, managed networking device or endpoint; networking engineers even got so smart to put alerts on these kinds of events using a whole other set of protocols like SNMP to "save our bacon" when things broke.

 

We know we have ways of making some packets go faster than others (queuing is a well defined and used system to achieve this, borne firstly for time sensitive applications like voice and video).  We also know we have ways of making things get distributed over the network faster or more optimally (see multicast for an example). 

 

There isn't a problem that the traditional issues in the audio realm (noise, interference etc) have that doesn't have a compensating control in the networking stack to ameliorate it.  If there was, it would have been fixed for much more important time critical or data sensitive applications like high frequency trading, financial settlements, video distribution networks or the plethora of IoT centric devices like PLCs that make your food, make your electricity or filter your water supply.  

 

Audio is a long way down the list of essential services IP networking provides and offers no unique problems to solve that haven't already been solved for other purposes.  Audiophiles are about as confused about networking as that kid with Beats headphones on his iPhone is with his Dad buying a $20k vinyl rig.

 

I'd write a best practice guide for your audio network and device selection if I figured it would get read and not debated. It's not that hard. We've had the recipe for years.

  • Like 4
Link to post
Share on other sites
7 minutes ago, Stereophilus said:

The argument about integrity of data transferred , buffered or stored are not part of the argument, as he is suggesting the variations occur at the DAC.

While amazingly sceptical, if that's the case, isolate the DAC using fibre like you can do on a Lumin X1 with an inbuilt SFP.  Another physical layer problem that networking has already solved.

Link to post
Share on other sites
2 minutes ago, Stereophilus said:

... suggesting upstream components of a DAC (talking specifically here about a device that is highly sensitive to timing errors) can influence the ground plane voltage and therefore threshold voltage for the DAC.

The claim in the article is that these small timing variations affecting a DAC are audible.

But while the audio is just bits contained in TCP/IP packets contained within Ethernet frames, there is no way that timing of the actual digital audio is affected. The content of those frames and packets is reconstituted, buffered and presented again as a digital audio stream by the endpoint equipment, not by the networking equipment. Or am I misunderstanding what is being said?

Link to post
Share on other sites
10 minutes ago, recur said:

While amazingly sceptical, if that's the case, isolate the DAC using fibre like you can do on a Lumin X1 with an inbuilt SFP.  Another physical layer problem that networking has already solved.

I’d encourage a re-read of the article, as he specifically covers this.

Link to post
Share on other sites
11 minutes ago, pwstereo said:

But while the audio is just bits contained in TCP/IP packets contained within Ethernet frames, there is no way that timing of the actual digital audio is affected.

This is correct, yes. 

Link to post
Share on other sites
11 minutes ago, pwstereo said:

But while the audio is just bits contained in TCP/IP packets contained within Ethernet frames, there is no way that timing of the actual digital audio is affected. The content of those frames and packets is reconstituted, buffered and presented again as a digital audio stream by the endpoint equipment, not by the networking equipment. Or am I misunderstanding what is being said?

As I read it, he is suggesting the ground signal variation / noise that piggy-backs along all the data cables (except optical fibre) is the issue, not the data.  The ground signal variation affects how the DAC reads those packets.

Link to post
Share on other sites

Regarding fibre:

 

Q. What about fiber-optic interfaces? Don’t these block everything?
A. In the case of a pure optical input (zero metal connection), this does block leakage current, but it does not block phase-noise affects. The optical connection is like any other isolator: jitter on the input is transmitted down the fiber and shows up at the receiver. If the receiver reclocks the data with a local clock, you still have the effects of the ground plane-noise from the data causing threshold changes on the reclocking circuit, thus overlaying on top of the local clock.

 

I can’t comment on the veracity of this answer, but it seems to suggest that the fibre receiver is just as prone to ground-plane noise transmission as any other upstream device.

Link to post
Share on other sites
2 hours ago, Stereophilus said:

If there was an explanation of why networks can affect the SQ of streamed music, would that change your perspective?  The best explanation of why network switches / routers and isolators affect audio SQ is here:

See here as to why it's voodoo science:

https://www.audiosciencereview.com/forum/index.php?threads/uptone-audio-etherregen-switch-review.10232/

  • Like 1
  • Haha 1
Link to post
Share on other sites
12 minutes ago, danrey said:

Yeah, i do keep abreast of that website, more for fun than anything else.  His DAC and power amp measurements are quite useful IMO.  There is a view that he measures the wrong things when it comes to upstream devices.

 

The article i posted was for interest and comment more broadly on ground plane noise, not for the specifics of the ER product (which can be discussed in the thread dedicated to it).

Edited by Stereophilus
Link to post
Share on other sites
21 minutes ago, Stereophilus said:

fibre receiver is just as prone to ground-plane noise transmission as any other upstream device.

The problem with the theory is that this concept of frame timing induced ground-plane noise transmission doesn't exist. And even if it somehow did exist, the idea of "re-generating" ethernet a spurious claim, because a switch, unlike a class II repeater, re-writes the frames from buffer every time anyway. The MAC receives the frame and doesn't bother the CPU until the frame has been copied to buffer memory, so there's no CPU involvement. And the cadence of frames is highly random in all cases anyway -- there's a reasonable assurance that on ethernet the frames will turn up in the right order most of the time, but their timing is going to be very loose (the client doesn't ask for data in a regimented fashion, the server doesn't send on the client's schedule, the network is going to be full of ad-hoc broadcast traffic anyway). 

 

Mr. rmpfyf asserts a hypothesis in a client device with very limited resources and/or bad design, there can be latency or jitter induced on the outgoing audio bitstream because of CPU interrupt workload, random packet timing, underfilled buffers or the like and proposes a strict-timing solution in the form of AES67. I respect his hypothesis while not endorsing his solution because I feel the technically correct solution to any and all timing problems is to have massive buffers on the client with audio processes running in the real time class. 

  • Like 1
Link to post
Share on other sites
7 hours ago, Hydrology said:

Trying to get my hands on a Waversa WSmartHub.

New Australian distributor so stock shouldn’t be too far away.

 

BDF24357-6EB9-42CC-9C5A-FB571BAC85AE.png.acaa309a6ccd6bc8e8ccdf06f35b25d0.png
 

 

 

 

 

 

 

 

Who's selling them and how much???

 

 

 

Link to post
Share on other sites
24 minutes ago, danrey said:

Just to flavour the pudding a bit more read these two reviews by Audio Bacon.  He listens.  They are not for the Etheregen.

 

https://audiobacon.net/2019/11/02/the-jcat-signature-lan-a-1000-ethernet-cable/

https://audiobacon.net/2019/04/05/sotm-snh-10g-audiophile-ethernet-switch-review/

John

 

Link to post
Share on other sites
18 minutes ago, PCOWandre said:

The problem with the theory is that this concept of frame timing induced ground-plane noise transmission doesn't exist. And even if it somehow did exist, the idea of "re-generating" ethernet a spurious claim, because a switch, unlike a class II repeater, re-writes the frames from buffer every time anyway. The MAC receives the frame and doesn't bother the CPU until the frame has been copied to buffer memory, so there's no CPU involvement. And the cadence of frames is highly random in all cases anyway -- there's a reasonable assurance that on ethernet the frames will turn up in the right order most of the time, but their timing is going to be very loose (the client doesn't ask for data in a regimented fashion, the server doesn't send on the client's schedule, the network is going to be full of ad-hoc broadcast traffic anyway). 

 

Mr. rmpfyf asserts a hypothesis in a client device with very limited resources and/or bad design, there can be latency or jitter induced on the outgoing audio bitstream because of CPU interrupt workload, random packet timing, underfilled buffers or the like and proposes a strict-timing solution in the form of AES67. I respect his hypothesis while not endorsing his solution because I feel the technically correct solution to any and all timing problems is to have massive buffers on the client with audio processes running in the real time class. 

If we can move past the “re-generation” concept, which relates to a specific product mentioned in the article.  I’m more interested in a general concept of ground plane noise being transmitted upstream of a DAC, through the CPUs, to arrive at the timing sensitive endpoint - the DAC.

 

I agree that none of the upstream components, CPUs, processors, are themselves jitter or timing sensitive.  I’m asking why these upstream devices acting as conduits for ground plane noise are NOT a potential cause for jitter within that DAC.  Data arrives at the DAC intact as an electrical signal that relates to a ground plane.  The variation in that ground plane is influenced by whatever is upstream alters how the DAC processes the data through timing error within the DAC... not upstream.

Edited by Stereophilus
Link to post
Share on other sites
3 minutes ago, pwstereo said:

Why is the terminology “ground plane”?

Harder to put numbers to. Easy to measure noise on a signal line as a potential vs ground, or noise across a balanced pair. By just saying "ground plane noise", it becomes a "noise" with nowhere to put your scope probes. And both the "WSmartHub" and "EtherRegen" run from wall warts with no mains ground coupling to be a reference. 

 

Given all electronics will radiate a bit of noise, I'd say the best way to get a good measurement on a device like this would be to back the voltage off on the signal until it was right at the bottom of standard, assuming nobody will be connecting 50+ metre cables. Less signal, less noise.

  • Thanks 1
Link to post
Share on other sites
1 hour ago, dbastin said:

So getting back to the topic of this thread, its not clear ro me if  @rmpfyf or anyone else provided a clear answer to my query which was along the lines of, what would be better than MikroTik?

 

Dale, it was in my post last night - good enterprise-grade switch > fibre > etherregen > very short CAT6 UTP lead > streamer.

 

So was the rationale, quite clearly. 

 

Most any second-hand enterprise-grade switch will do.

Link to post
Share on other sites
58 minutes ago, danrey said:

 

Please dude. Amir's jitter measurements and visualisations are a joke, that's coming from someone with a professional background in digital signal processing (me). 

 

I'd launch a website called AudioBetterScienceReview so I could talk down to people that didn't know better on a regular basis but I'm not that insecure. 

  • Thanks 1
Link to post
Share on other sites
22 minutes ago, pwstereo said:

Why is the terminology “ground plane”?

It doesn’t seem right in this situation.

The Ethernet signal is on multiple twisted pairs.

Once again, I will defer to the article.  I don’t want to copy and paste too much, but he does explain this concept quite clearly.  Beyond that, I’m not much use.  I am interested to hear valid arguments against the theory he presents though. Not so much interested in the device he sells, just the theory in this article. So far it still seems very logical to me.

Link to post
Share on other sites
10 minutes ago, rmpfyf said:

 

Please dude. Amir's jitter measurements and visualisations are a joke, that's coming from someone with a professional background in digital signal processing (me). 

 

As a software engineer who has worked in digitising tv broadcast environments in this country, i'm all ears as to why it's badly done.

Link to post
Share on other sites
Just now, danrey said:

As a software engineer who has worked in digitising tv broadcast environments in this country, i'm all ears as to why it's badly done.

Pull up any one of his jitter plots and show me the relevant part, and how it was acquired. 

Link to post
Share on other sites
1 hour ago, recur said:

Audio is a long way down the list of essential services IP networking provides and offers no unique problems to solve that haven't already been solved for other purposes.  Audiophiles are about as confused about networking as that kid with Beats headphones on his iPhone is with his Dad buying a $20k vinyl rig.

 

I would go a little easy and offer another perspective, not least as (from a scientific perspective) I don't think @dbastin, @Assisi and others are hearing things. I run similar experiments and the differences are palpable. 

 

We need to get beyond this being about the data or anything in the actual networking stack. The data arrives fine.

 

We also need to get beyond a notion of 'there's a buffer therefore it's a moot point'. That's not what buffers are for. They are not infinite in size. They store data, they don't offload interrupts. 

 

Fundamentally we're dealing with how the endpoint behaves relative to how the data arrives

 

Build a toolstack to measure some direct and not-so-indirect measures - OS jitter is a good thing to try to capture. It'll change on MTU, speed, pretty much anything you can throw at it. Not all changes are large.

 

This isn't like async USB where there's a timed relationship to when and how data arrives, though (AES67 argument again) the capability exists within networking - it is not implemented here.

 

1 hour ago, recur said:

There isn't a problem that the traditional issues in the audio realm (noise, interference etc) have that doesn't have a compensating control in the networking stack to ameliorate it.  If there was, it would have been fixed for much more important time critical or data sensitive applications like high frequency trading, financial settlements, video distribution networks or the plethora of IoT centric devices like PLCs that make your food, make your electricity or filter your water supply.  

 

I'd take issue here as in ultra-time-critical stuff there's network tech that isn't part of usual Eth transfer. Though it could be added, and emerging standards exist to deal with this. Till then we have punters trying to make things better (very) indirectly.

 

There's also this -

 

34 minutes ago, Stereophilus said:

I agree that none of the upstream components, CPUs, processors, are themselves jitter or timing sensitive. 

 

Very much untrue. A modern CPU is extremely timing sensitive, and in particular the way it manages power states (very) quickly and the knock-on effects for upstream power system design mean a modern PC is a rig designed for flexible power scaling, not for rock-steady repeatable periodic performance - and the two really are quite opposing design goals. Now it's not timing-sensitive in a way that a minor timing issue will throw out functionality, it's the inverse - it's inherently designed to be highly tolerant of timing variance. That doesn't mean timing is important, it means that if you want a CPU to deliver an outcome in a highly resolute and dependent way, it'll be done indirectly and with very specific controls. 

 

These problems are ultimately well towards the bleeding end. Optimised network and non is not a gulf between awesome and unlistenable unless something is really, really wrong. Electrical noise isn't making its way to DAC ICs unless there's a cascade of very sloppy design at play.

 

But it's not right to suggest it doesn't exist.

Link to post
Share on other sites
  • Recently Browsing   0 members

    No registered users viewing this page.




×
×
  • Create New...