Jump to content

Recommended Posts

  • 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

8 minutes ago, recur said:

Not really. Nothing Occam's Razor couldn't have fixed first.

 

image.png.2adf02abbcffd63d9e8ffad8c780ef62.png

Occam's Razor discounts a given explanation for events doesn't prove that explanation right or wrong, it's just a useful guideline. ... On the other hand, reality is sufficiently complex that sometimes explanations are complex.

 

In this instance of the divergence of relative experience and opinion, I do not think it would have resolved anything.

 

John

Link to post
Share on other sites

I am now intrigued about how these Music Servers stream and to how loss of data is managed or not  ..  its been a while since I have researched into Networking protocols so you may already know all about this one ... if so my apology ..  hopefully some will find it interesting ... as a keen TIDAL user I did some searching and this is where I found the reference that Tidal uses QUIC ... if I understand simplistically it builds on UDP and adds the transport layer at the application layer ... its widely implemented, including Google, Microsoft and used by companies such as Akami.  Now this may be right or wrong that its being used by Tidal  ...   the video is interesting as it covers TCP, UDP and earlier development by Google of QUIC. 

 

Wikipedia ...

 

QUIC aims to be nearly equivalent to a TCP connection but with much-reduced latency. It does this primarily through two changes that rely on the understanding of the behaviour of HTTP traffic.[17]

 

The first change is to greatly reduce overhead during connection setup. As most HTTP connections will demand TLS, QUIC makes the exchange of setup keys and supported protocols part of the initial handshake process. When a client opens a connection, the response packet includes the data needed for future packets to use encryption. This eliminates the need to set up the TCP connection and then negotiate the security protocol via additional packets. Other protocols can be serviced in the same way, combining together multiple steps into a single request-response. This data can then be used both for following requests in the initial setup, as well as future requests that would otherwise be negotiated as separate connections.[17]

 

QUIC uses UDP as its basis, which does not include loss recovery. Instead, each QUIC stream is separately flow controlled and lost data retransmitted at the level of QUIC, not UDP. This means that if an error occurs in one stream, the protocol stack can continue servicing other streams independently. This can be very useful in improving performance on error-prone links, as in most cases considerable additional data may be received before TCP notices a packet is missing or broken, and all of this data is blocked or even flushed while the error is corrected. In QUIC, this data is free to be processed while the single multiplexed stream is repaired.[18]

 

QUIC includes a number of other more mundane changes that also improve overall latency and throughput. For instance, the packets are encrypted individually, so that they do not result in the encrypted data waiting for partial packets. This is not generally possible under TCP, where the encryption records are in a bytestream and the protocol stack is unaware of higher-layer boundaries within this stream. These can be negotiated by the layers running on top, but QUIC aims to do all of this in a single handshake process.[8]

 

Another goal of the QUIC system was to improve performance during network-switch events, like what happens when a user of a mobile device moves from a local WiFi hotspot to a mobile network. When this occurs on TCP, a lengthy process starts where every existing connection times out one-by-one and is then re-established on demand. To solve this problem, QUIC includes a connection identifier which uniquely identifies the connection to the server regardless of source. This allows the connection to be re-established simply by sending a packet, which always contains this ID, as the original connection ID will still be valid even if the user's IP address changes.[19]

 

QUIC can be implemented in the application-space, as opposed to being in the operating system kernel. This generally invokes additional overhead due to context switches as data is moved between applications. However, in the case of QUIC, the protocol stack is intended to be used by a single application, with each application using QUIC having its own connections hosted on UDP. Ultimately the difference could be very small because much of the overall HTTP/2 stack is already in the applications (or their libraries, more commonly). Placing the remaining parts in those libraries, essentially the error correction, has little effect on the HTTP/2 stack's size or overall complexity.[8]

 

This organization allows future changes to be made more easily as it does not require changes to the kernel for updates. One of QUIC's longer-term goals is to add new systems for forward error correction (FEC) and improved congestion control.[19]

 

 

 

Edited by Rosco8
Link to post
Share on other sites

QUIC always come across (to me) as another dose of Google hegemony and part of their love of destroying simplicity and burying everything knee-deep in proprietary goo that is just "open" enough to play the Open card. 

 

One of the truly beautiful things about HTTP was the simplicity. It wasn't hard to build a basic HTTP stack and it certainly wasn't hard for anyone to debug problems armed with telnet alone. 

 

HTTP/2 was pretty much a failure, with the cases where it should have made a big improvement often yielding a net decrease in performance. 

 

This rant captures a lot of the vibe for me:

 

https://www.roguelazer.com/2020/07/etcd-or-why-modern-software-makes-me-sad/

 

That's certainly not to say I can't see what they're trying to do or why they're trying to do it -- it just feels like another wave of complexity that caters to the operators of large decentralised advertising networks at the expense of smaller operators, network simplicity and transparency. 

Easy to avoid QUICC, though - just force use of an http proxy and it'll have to fall back to http/https.

  • Like 1
Link to post
Share on other sites


20 minutes ago, PCOWandre said:

QUIC always come across (to me) as another dose of Google hegemony and part of their love of destroying simplicity and burying everything knee-deep in proprietary goo that is just "open" enough to play the Open card. 

One of the truly beautiful things about HTTP was the simplicity. It wasn't hard to build a basic HTTP stack and it certainly wasn't hard for anyone to debug problems armed with telnet alone. 

This rant captures a lot of the vibe for me:

https://www.roguelazer.com/2020/07/etcd-or-why-modern-software-makes-me-sad/

That's certainly not to say I can't see what they're trying to do or why they're trying to do it -- it just feels like another wave of complexity that caters to the operators of large decentralised advertising networks at the expense of smaller operators, network simplicity and transparency. 

Yeh, I get it ...

 

I saw that there were already 4 thread versions which means 4 sets of devs doing their thing ... reminds me of SQL .. everyone adding their own enhancements trying to lock you in ... destroys the concept of open standards ....   it can still be done within a standards framework and SGML (XML borrowed a lot from SGML) is an example where in the aeronautical world, the 3 core standards being FIXM (flight), AIXM (aero ground) and WXXM (weather) they defined localized (user defined) extension frameworks so you can effectively add on what you wanted by country, which was needed because Internationally countries have differences and as an example getting a dozen European countries to agree with the USA is nigh impossible and vice versa  ..  however it all used the same syntax and is textual so can be read easily and harmonisation forums were put in place to ensure no duplication and that the extensions made sense.

 

Still some clever stuff in QUIC ..  2 edged swords ...

Link to post
Share on other sites
14 minutes ago, Rosco8 said:

Still some clever stuff in QUIC ..  2 edged swords ...

I think it's a bit like DNSoHTTPS. One can argue some very positive sides (less carrier intrusion into traffic, analytics, etc) but one can also see it as a way of removing common DNS blocks that are used for skipping advertising networks, or putting that DNS data in the hands of Cloudflare or Google instead. 

Link to post
Share on other sites
5 hours ago, davewantsmoore said:

"A little misleading"   ?!?!?!?

 

LOL LOL LOL

He may as well be telling people up is down.

 

You're shortselling the presentation, Dave.

 

He's telling people up is down and he has a solution that is a little bit less down, and that he's been the first to notice the alleged discrepancy.

Link to post
Share on other sites

Many here are still looking at the wrong thing. 

 

There is nothing in bog-standard Ethernet that limits the ability of the data to get through. 

 

Any performance differences are going to be realised as small changes in OS jitter on the receive end. Period. There's a ton of work dedicated to OS jitter as a function of interrupt performance for many real-time-like applications particularly in Linux, it's dense reading but you'll find all you need to read there. The problem is not as simple as 'there's a buffer there' nor is it solved similarly.

 

And frankly there are solutions that don't involve extremely conductive cables, noise-free digital signal square waves or well-tempered clocks in your Ethernet router. In most applications tweaking CPU affinity and using large buffers around independent processes will do the job. Most streamers, no matter how expensive, don't actually do this. There's a ton that can be done for realtime performance in OS builds that isn't done in most audio builds. 

 

Finally there are networking standards that force time synchronisation of packets where that's useful. Again (flogging a dead horse) AES67 deals with this well. 

 

The people that have nice routers and switches etc are not hearing things. It's quite real. I have no doubt. Seriously.

 

But a few people with tuned networks on very ordinary cabling on some attention to detail and standard routers, with very simplistic operating systems and significantly buffered players are probably getting better sound. 

Link to post
Share on other sites


4 minutes ago, rmpfyf said:

The people that have nice routers and switches etc are not hearing things. It's quite real. I have no doubt. Seriously.

 

But a few people with tuned networks on very ordinary cabling on some attention to detail and standard routers, with very simplistic operating systems and significantly buffered players are probably getting better sound. 

 

I'm hesitating to weigh into this too much being new here but, I do not agree. A nice router or a nice switch does not equal hearing 'better quality audio' full stop.

 

Your opening statement was true for broadcast quality networks that due to architecture that was correct at the time (things have changed I'm sure) required low-latent point-to-point fibre transmission to get the most out of their live transmission.

 

As new as I am to audio, 'real-time' for home audio is false idea. Live broadcast media, different story. 

 

Any suggestion that your network device(s) - and I am talking on premise only, no streaming from Internet hosted services - are introducing any audio degradation can only be a result of interference with the power of said units (maybe, stretch) and not the underlying technology that is transmitting the content. The keyword here is transmitting and NOT transforming*.

 

For audio that is streamed via Internet services there is also variable bitrate (VBR) to consider which can vary the quality of the media (audio or video) streamed to/from a device based on how the control plane measures available resources, e.g.; throughput, jitter, packet loss. Only then (unless your home network is congested) would one experience variance in audio quality.

 

*Ethernet hardware and the protocol is for transport. Only when the transport mechanism introduces constraints such as bandwidth, loss and latency, such as Bluetooth, does one then transform media with codecs to deal with the constraints by the transport medium.

 

Link to post
Share on other sites
56 minutes ago, bigev said:

 

I'm hesitating to weigh into this too much being new here but, I do not agree. A nice router or a nice switch does not equal hearing 'better quality audio' full stop.

 

Your opening statement was true for broadcast quality networks that due to architecture that was correct at the time (things have changed I'm sure) required low-latent point-to-point fibre transmission to get the most out of their live transmission.

 

As new as I am to audio, 'real-time' for home audio is false idea. Live broadcast media, different story. 

 

Any suggestion that your network device(s) - and I am talking on premise only, no streaming from Internet hosted services - are introducing any audio degradation can only be a result of interference with the power of said units (maybe, stretch) and not the underlying technology that is transmitting the content. The keyword here is transmitting and NOT transforming*.

 

For audio that is streamed via Internet services there is also variable bitrate (VBR) to consider which can vary the quality of the media (audio or video) streamed to/from a device based on how the control plane measures available resources, e.g.; throughput, jitter, packet loss. Only then (unless your home network is congested) would one experience variance in audio quality.

 

*Ethernet hardware and the protocol is for transport. Only when the transport mechanism introduces constraints such as bandwidth, loss and latency, such as Bluetooth, does one then transform media with codecs to deal with the constraints by the transport medium.

 

 

I do not agree with you. Two full stops. 

 

There is no audio degradation to be had. None. Zero. For the millionth time, nothing is lost in transport. The bits get there intact. There is no debate here. I have a CAT3 cable somewhere here and when I find it I am happy to mail it to anyone that disagrees.

 

This is about timing accuracy at the endpoint, nothing less and nothing more. 

 

it's as basic as using packetised architecture to generate a stream. Timing variance, no matter how small, is inevitable. 

 

The point of using a real-time OS or an OS with real-time extensions is simply to manage priorities. In particular those associated with playback and networking, and to not have resources need to tend to both when one is a primary task. Network behaviour at the NIC can affect audio playback even when the playback material is fully buffered locally. This has nothing to do with any transport issues. Nothing. Play anything on a Linux machine over a network using aplay; whilst it happens flick the NIC interrupt from CPU to CPU. It's often audible. There is no degradation, there is no data loss. But there is a difference. It's just slightly so in timing.

 

A nice switch and uber cabling is a daft way of eliciting periodicity enough to tame noise and any inherent randomness in network data because these are at best very, very indirect ways of optimising the phenomena at hand. They are the sort of solutions borne of 'traditional' audio thinking where better wires, better timing, better interconnects, better isolation all work in analogue or stream domains. 

 

The very point of packet-based networks is to not need any of that. And that's a paradigm that extends beyond the NIC and into the node. Getting some NIC interrupt sensitivity? Buffer locally, deliberately so, and sort process and interrupt priorities. Sorted. Getting conducted noise in (if you think so)? Fibre. These  are direct solutions and they are very, very effective.

 

I am totally in love with the notion of AES67 as I can have multiple speakers on a network and literally employ a digital solution for timing accuracy of whatever specification I desire.

 

In the meantime I've a PC with some network tuning, some OS tuning, very simple playback from RAM and very happy listening.

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

A nice router or a nice switch does not equal hearing 'better quality audio' full stop.

@bigev,

 

Another full stop in bold.

 

There are several other posters in this thread that are on the same page as you and reside in the same universe.  There are a few posters including myself who fortunately  reside in a parallel universe. 

 

@rmpfyfacknowledges that:

“The people that have nice routers and switches etc are not hearing things. It's quite real. I have no doubt. Seriously

My assumption reading all his posts is that he has questions on the networking methodology and possible expense of what somebody like me has achieved.  His position seems to be that there are other methodologies that are less expense to achieve an equivalent outcome.  That maybe so.  To me his methodologies are too complex for me.  I can buy something, easily connect it up and it works and life is much better.

 

 

Possibly the cosmologists are correct and there is more than one universe.  I definitely live in one different to you.  I have implemented improvements to my audio network arrangements on a staged basis over time.  The progressive benefit has been significant.  If you listened to my system, I am sure that you would leave asking yourself the questions what is happening and why?  I still ask myself those same questions.   If you have not experienced a network configured for audio you have missed something I can assure you.

 

John

Edited by Assisi
  • Like 3
Link to post
Share on other sites


17 hours ago, PCOWandre said:

I just put together an anonymous survey -- there's not even an option to leave a name. C'mon, let's weigh in and we'll discuss the stats when we're done:

 

https://nc.purplecow.org/index.php/apps/forms/Sj3aRs2ffd5xcyjG

Seems like this survey has put an end to the debate. 

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

anonymous survey

I did the survey.  Sounds like some market research for a start up. 

 

There's a few key questions missing, but they may only make sense to people from the parallel universe John and I are in.

 

The bottom line answer for me is, I dont care how it looks or if its 'audiiphile' or not, or consistent with conventional/mainstream networking knowledge ... if it improves sound quality and is reasonably priced for what sound quality it achieves, I am willing to try it.

  • Like 2
  • Haha 1
Link to post
Share on other sites
18 minutes ago, dbastin said:

Sounds like some market research for a start up. 

Aww, hell no. There's no way I'd want to be launching a start up in that space. That way madness lies!

 

 

  • Haha 1
Link to post
Share on other sites


OK, everyone has had some time to chime in with an opinion. I'll leave it open and if there are many more replies I'll post an update on Monday.

 

image.png.633e9cb568a87365adad0ed9e1cd413b.png

 

Of the fifteen respondents, eight were looking for incremental upgrades without changing their major components. Four people thought optical fibre was cool and wanted to get some of that. Two felt that while enterprise graded equipment would be nice, the noise and heat was intolerable.

 

Seven people stated they didn't want fancy-looking cables that made no promises. Seven people would consider such a purchase. 

 

Ten had no interest in network elements designed to be solid and cosmetically pleasing without promising specific audio advantages. Four suggested they would, but there was no consensus about that what such a component should look like. 

 

And for the grizzly opinions of the network professionals? 

 

I think "Network Experts" are dismissive of subjective reports and ...

image.png.2757b2cbe9198229fe89d3e1f84b769a.png

 

Notably, zero respondents stated they planned to purchase audiophile-specific network equipment. Either potential buyers had already left the thread, or the appeal just isn't there.

 

Obviously the survey size is very small. Not wide enough to be statistically significant nor represent the broader SNA community. But I think it was entertaining and gave me a chance to test the NextCloud "forms" functionality. 

 

Meanwhile, it seems like the one easy to fulfull desire is to get cables that don't look crappy, so perhaps there's an opportunity for a group buy to get some patch cables made up locally with some nice braid sleeve. I'm assuming the total cost would be in the order of $30/cable. 

 

For those adding fibre to their network, make sure you get the right colour. Aqua/OM4 should be your minimum since you'll want to re-use it for 10 gig later on. 

 

 

Link to post
Share on other sites

The question that immediately springs to mind is... Given this thread is named "ethernet routers for Audio", why are 2/3 or respondants content with their network setup and not interested in upgrading?  Are they just here to troll?

Edited by Stereophilus
  • Like 1
Link to post
Share on other sites
18 minutes ago, PCOWandre said:

They could be answering questions rather than asking them?

Pause and reflect on the content of this thread... how many of those “answers” have been the repetitive bleating of “ bits is bits is bits is bits is bits...” (always carefully paraphrased to sound like it is a somehow unique and novel argument)?
 

Those of us who actually experiment, because we enjoy the hobby, the music and the journey, sometimes (not all the time) hear a difference.  We come to threads like this not just for answers, but to share experiences.  Real experiences... not the regurgitated ideas of Amir at ASR, or the misguided do-gooders wanting to help us out by saving our mis-spent coin.  Hobbies are for fun and experimenting and spending (sometimes frivolously). 

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

Well listening to music isn't just about just specs, nor the speakers or cables or even the music it self. It is the experience that counts. 

 

Even if bits stays bits and doesn't change anything by adding audiophile ethernet cables and switches but if it does improve the experience, than that is all its about.

 

The other day, I had the pleasure of visiting another SNA member and got to listen to his very high end gear in very large space through tiny JBL 4312MII speakers and that experience has been mesmerising. May be it was the another person who was genuinely interested in sharing his listening pleasure with me, or may be I was just listening to new gear other than mine and had enjoyed it very much. I don't know what it was, but It was the experience as a whole that was mesmerising. 

 

So, leaving aside what we know and what we don't about network and audio, and if by adding an audiophile ethernet cable or network switches adds to that experience than, that is the main pursuit here.

  • Like 2
  • Love 1
Link to post
Share on other sites
4 minutes ago, :) Go Away (: said:

 

Well listening to music isn't just about just specs, nor the speakers or cables or even the music it self. It is the experience that counts. 

 

Bam! That’s it in its entirety. But the music is the experience.

  • Like 1
Link to post
Share on other sites
17 minutes ago, :) Go Away (: said:

May be it was the another person who was genuinely interested in sharing his listening pleasure with me

For millennia, music has been a shared experience. I think there's a very good reason for that. 

  • Like 3
Link to post
Share on other sites
54 minutes ago, Stereophilus said:

how many of those “answers” have been the repetitive bleating of “ bits is bits is bits is bits is bits...”

I think there's a gulf of difference between the classic "bits is bits" crowd and a discussion of ethernet and IP networking. I don't see the participants in this thread being the same as Amir's army of Chi-Fi salesmen. 

 

By and large, IP networking and the supporting physical layers are misunderstood, including by experienced IT professionals who just haven't worked in that space. As more of the industry becomes cloud-native, understanding of networks and ethernet are going down. 

 

I believe there is a campaign of deliberate misinformation being disseminated by cable vendors and their ilk to portray ethernet as being akin to S/PDIF; a time-sensitive medium without robust transmission. In fact, a video posted upthread (or was that in the cabling thread?) even claimed there was no error checking or retransmission on a TCP connection. That's just a barefaced lie. Claims that only certain devices "regenerate" or "reclock" ethernet are also false, because the store 'n' forward nature of a switch means every frame is fresh from the bridge. 

 

It certainly isn't about begrudging anyone their enjoyment of nice things. Certainly, if we were to live by other people's measurements and opinions, we'd all be sitting with nought but "Topping" boxes watching a movie instead of listening to a symphony. 

 

Finally, in the spirit of cooperation rather than just arguing, I'm willing to test, configure and firmware upgrade any reasonable* enterprise network switch that any prior poster in this thread chooses to acquire. Just pick up the shipping and I'll make sure gets to you with sensible settings, IP address configured and ready to use. I assume not everyone has a serial console handy and some of these network elements don't play nicely with USB/RS-232 dongles. 

 

* Reasonable is defined broadly as Cisco, Mikrotik, ProCurve. 

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

I believe there is a campaign of deliberate misinformation being disseminated by cable vendors and their ilk to portray ethernet as being akin to S/PDIF; a time-sensitive medium without robust transmission. In fact, a video posted upthread (or was that in the cabling thread?) even claimed there was no error checking or retransmission on a TCP connection. That's just a barefaced lie. Claims that only certain devices "regenerate" or "reclock" ethernet are also false, because the store 'n' forward nature of a switch means every frame is fresh from the bridge. 

The Audio hobby certainly is prone to hyperbole.  The problem is, something seems to happening between the router and the DAC (inclusive of those devices) that can influence sound quality.  I’m not saying I know what is happening, but it’s a real thing.  The message here to “networking experts” is can you help us understand where the the network might contribute to changes in sound quality? That way we can all benefit, and make more discerning choices that reward the true engineers over the snakeoilers.  I think @rmpfyf tries really hard to do this.

Quote

 

It certainly isn't about begrudging anyone their enjoyment of nice things. Certainly, if we were to live by other people's measurements and opinions, we'd all be sitting with nought but "Topping" boxes watching a movie instead of listening to a symphony. 

 

Finally, in the spirit of cooperation rather than just arguing, I'm willing to test, configure and firmware upgrade any reasonable* enterprise network switch that any prior poster in this thread chooses to acquire. Just pick up the shipping and I'll make sure gets to you with sensible settings, IP address configured and ready to use. I assume not everyone has a serial console handy and some of these network elements don't play nicely with USB/RS-232 dongles. 

 

* Reasonable is defined broadly as Cisco, Mikrotik, ProCurve. 

That’s a very decent offer and one I might take you up on.  Do you anticipate that in doing so I might notice a change in my streaming audio sound quality?

Edited by Stereophilus
Link to post
Share on other sites
1 minute ago, Stereophilus said:

That’s a very decent offer and one I might take you up on.  Do you anticipate that in doing so I might notice a change in my streaming audio sound quality?

Your signature suggests you're using an Antipodes CX. I'm not familiar with the CX, but I did read some of the earlier Antipodes documentation recently while looking at another thread, and it appears that the core music playing "engine" of the Antipodes is mpd. Given the robust nature of mpd combined with the usually generous specs of the Antipodes series, I'd be surprised if you'd gain anything unless you had an identified fault condition such as noise ingress, gaps or stuttering in playback. If the Antipodes gives you multiple player app options, I'd strongly recommend giving mpd a thorough audition to see how it performs for you. If it permits, try to use NFS to connect your NAS instead of SMB which is more robust.

 

In terms of streaming services such as Tidal, as long as your network is fully functional and you aren't having obvious problems -- like the aforementioned noise ingress or stuttering in playback -- there's probably nothing to be gained. Because of external network factors, streaming apps are designed to hold quite a large buffer so your music doesn't start skipping when someone else in the house starts a youtube video playing. 

 

I'd tend to endorse replacing consumer network kit with good commercial or enterprise equipment, but you need to factor in size and noise, as well as ongoing maintenance. I'd probably have to recommend against replacing your router unless you had the time to learn how to drive the replacement. Switches generally don't get too much in the way of config changes in a home environment, so they're easier to deal with. 

 

If you think you have a problem with decreased throughput and your cable is installed in the walls, pull the wall plate and inspect the terminations. There should be almost zero untwisted wire going to the keystone. When the network requirements are very low (like streaming audio), horrible network packet loss can hide behind TCP and lead to irritation. There have been a lot of cases of bad installs turning up lately, with cabling that only meets cat3 standards due to length of untwisted pairs. 

 

 

  • Like 1
Link to post
Share on other sites

Oh, and reboot your kit every now and again, even if it doesn't need it. I've found some of these USB audio interfaces get a little .. special .. after a few weeks without interruption. 

  • Like 1
Link to post
Share on other sites

We're 6 pages into this thread and I think we've had a fair bit a venting, and established we have some members with immense expertise in networking, and some members who have explored alternatives to the conventions and discovered gains in sound quality, on some systems that are very good to say the least.

 

Both groups have serious cred, and seem to be aligning in their pursuit for greater enjoyment, better experiences of music and the systems that convey it.

 

As an aside, the enjoyment makes a great contribution to our wellbeing.  And working together to achieve things can also be rewarding in many ways other than the achievement.  All this can be enriching.

 

I created this thread (and others about ethernet for audio) with a hope to create resources for members to benefit, and improve their enjoyment.  Ultimately, once we explorre routers, I have in mind creating a thread 'Ethernet Systems for Audio: Putting it all together' with a view to creating a resource to help understand what components to use where, to balance their impact and bang for buck.  To help novices navigate this rabbit hole which is more of a rabbit warren (aka, network).

 

I suggest we develop a specification.  What does a router need to be optimal for audio.  Then go about finding products that meet the specification.  Then develop easy tò follow guide to configure/set them up. 

 

I suggest we try to choose products that dont need a console, ie. more user friendly.  But if a console is needed, there could be an opportunity for sideline income for those that can access one and have the expertise to use it.

 

I'm gonna kick off ...

 

The Specification

 

1. SFPs, ideally 4 or more, ie:

- 1 for input from nbn (via media convertor)

- 1 for audio system

- 2 + for rest of network (ie. to switches)

 

2. Capable of being powered by external PSU with litte or no modification.

 

3. fanless or very quiet for placement in listening room (so can be powered via audio system power conditioner).

 

4. User friendly by people with little or no networking expertise.

 

5. cost? say up to $1k.

 

Feel free to suggest additions.

 

Dale

Edited by dbastin
  • Like 2
Link to post
Share on other sites

I mentioned ECTs previously.  I was referring to Synergistic Research ECTs (Electronic Circuit Tranducers).

 

I have 5 of these in strategic locations on the ethernet route to my endpoint.  Each one provides an incremental minor to moderate improvement in sound quality, and it is cumulative.  I dont fully understand why, it just is.

 

So I now put one more in, on the isolation transformer in my Ubiquiti EdgeRouter X SFP.  Again it provided another improvement, which took a few songs to fully appreciate but now I have learned it, it is unmistakeable.

 

For context, there is bog standard Cat 5e UTP from EdgeRouter to the next switch. Soon to be replaced with fibre.

 

Incidentally I had previously removed the SSD and all sata cabling from my Antipodes EX.  The sound now is considerably better than playback from SSD.

 

The twist ... my system has 5 devices that buffer ethernet data enroute to endpoint and it plays for about a minute when the router it disconnected.  Even so, when the router is now connected, it is the best sound I've had.

 

I can't explain why.  It is mysterious.

20200919_090001.jpg

Edited by dbastin
Link to post
Share on other sites
On 16/09/2020 at 7:04 PM, rmpfyf said:

Not least as you're straight into solution mode, which is a dangerous place to be given what needs to be understood here.. Not least as there are very many solutions - how many fibre ports? What type? What support? What are your space requirement? Noise? Etc.. There's quite literally a plethora of solutions out here.

What specification would you suggest for best audio outcome in a typical household?

Link to post
Share on other sites
12 hours ago, PCOWandre said:

Your signature suggests you're using an Antipodes CX. I'm not familiar with the CX, but I did read some of the earlier Antipodes documentation recently while looking at another thread, and it appears that the core music playing "engine" of the Antipodes is mpd. Given the robust nature of mpd combined with the usually generous specs of the Antipodes series, I'd be surprised if you'd gain anything unless you had an identified fault condition such as noise ingress, gaps or stuttering in playback. If the Antipodes gives you multiple player app options, I'd strongly recommend giving mpd a thorough audition to see how it performs for you. If it permits, try to use NFS to connect your NAS instead of SMB which is more robust.

 

In terms of streaming services such as Tidal, as long as your network is fully functional and you aren't having obvious problems -- like the aforementioned noise ingress or stuttering in playback -- there's probably nothing to be gained. Because of external network factors, streaming apps are designed to hold quite a large buffer so your music doesn't start skipping when someone else in the house starts a youtube video playing. 

 

I'd tend to endorse replacing consumer network kit with good commercial or enterprise equipment, but you need to factor in size and noise, as well as ongoing maintenance. I'd probably have to recommend against replacing your router unless you had the time to learn how to drive the replacement. Switches generally don't get too much in the way of config changes in a home environment, so they're easier to deal with. 

 

If you think you have a problem with decreased throughput and your cable is installed in the walls, pull the wall plate and inspect the terminations. There should be almost zero untwisted wire going to the keystone. When the network requirements are very low (like streaming audio), horrible network packet loss can hide behind TCP and lead to irritation. There have been a lot of cases of bad installs turning up lately, with cabling that only meets cat3 standards due to length of untwisted pairs. 

 

 

My music is streamed thusly:

NBN modem -> basic wifi router -> cat 6 wired network -> Optical converter -> optical fibre -> Music room switch -> AQ cinnamon Ethernet cable  -> Antipodes CX -> Antipodes Ethernet cable -> Mola Mola Makua
 

The CX is a Roon core and the Makua is a Roon ready endpoint.  Other players are not an option for the Makua endpoint currently.  So no MPD.

 

The Ethernet connection from the CX to the Makua is, I believe programmed to be a subnet.  It is certainly the best sounding of the connection options.

 

I have no music room network “issues” as such.  Everything works.  Nonetheless, changing power supplies to the optical converter and the switch change the sound quality in a small way..  Changing the power supply to the router makes no difference.  
 

Link to post
Share on other sites
On 16/09/2020 at 7:04 PM, rmpfyf said:

If you're going to try to hotrod any component it'd be the switch, not the router, though think of what you can actually change - there's no EMI down a fibre line, only packet timing.

So, I'm not sure my experience with ECTs aligns with this.

 

I have nbn box > Cat 5e > router > Cat 5e > switch > fibre > EtherRegen > Wireworld Platinum > Antipodes EX > JCAT Signature Lan > Gigifoilv4  > Synergistic Research Atmozphete X Ref > endpoint.

 

So on that route there is 2 x fibre isolations, 2 x electronic isolations, 2 x cables that noticeably reduce noise, 5 x ECTs, but 1 ECT in router still gave an improvement in sound quality.  The Gigafoilv4 in particular is not an audio product however my feeling is its impact exceeds the EtherRegen - I'd guess its fibre isolation plus clocking is superior.

 

I'm not seeking an explanation, moreso just observing there are some mysterious things going on.

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

The CX is a Roon core and the Makua is a Roon ready endpoint.  Other players are not an option for the Makua endpoint currently.  So no MPD.

The Makua is a nice preamap. Very nice. I really like the way they don't skimp out on balanced inputs and try to palm off 2 balanced and six RCA as somehow acceptable. 

 

I've got a lot of growing concerns about the extent that Roon has managed to lock-in the market. When they go out of business, there's going to be a lot unhappy people 

 

Anyway, I think you've got it pretty much nailed. Good set up.

 

I have a roaring hatred of media converters, born of seeing them being a failure-prone device in the field that always breaks between midnight and dawn. So I'd say if you can lose that in favour of a switch with the right connectivity, that'd be a reliability winner. 

 

How much of your listening is Tidal vs your own music?

  • Like 1
Link to post
Share on other sites
On 17/09/2020 at 5:04 PM, rmpfyf said:

The people that have nice routers and switches etc are not hearing things. It's quite real. I have no doubt. Seriously.

 

But a few people with tuned networks on very ordinary cabling on some attention to detail and standard routers, with very simplistic operating systems and significantly buffered players are probably getting better sound. 

How can lessons from the 2nd 'few people' be translated into things the majority of us can use and do?

  • Like 1
Link to post
Share on other sites
36 minutes ago, dbastin said:

What specification would you suggest for best audio outcome in a typical household?

No such thing, mate! Well, no such thing as a typical household where the stereo costs more than the average car. Hah.

 

That's why it always has to start with requirements and end with requirements. 

 

19 minutes ago, dbastin said:

I have nbn box > Cat 5e > router > Cat 5e > switch > fibre > EtherRegen > Wireworld Platinum > Antipodes EX > JCAT Signature Lan > Gigifoilv4  > Synergistic Research Atmozphete X Ref > endpoint.

Another happy Antipodes customer. A cynic would suggest that there's now a link between Antipodes and network sensitivity, but we know that isn't so.

 

I'll post the same question as above -- how much is Tidal et vs your own music? I'm not seeing a NAS called out in your path. 

 

If you just feel like changing it up a little, I'd again point to a switch replacement to something managed as bit of general good network housekeeping. 

Link to post
Share on other sites
20 minutes ago, dbastin said:

But a few people with tuned networks on very ordinary cabling on some attention to detail and standard routers, with very simplistic operating systems and significantly buffered players are probably getting better sound. 

 

20 minutes ago, dbastin said:

How can lessons from the 2nd 'few people' be translated into things the majority of us can use and do?

 

Pretty easily, really. Budget $250-ish and a day or two of fiddlin' time to try the highly buffered mpd-centric solution and give it a try. The software is all free, the hardware requirements are very cheap and if you don't like the outcome you can probably onsell the whole lot on the forums here to someone else looking to give it a go. 

 

I know this is absolutely heresy in the hifi world, but I don't think Roon is the be-all and end-all of network delivered music. It might be the prettiest and have the nicest interface, but the combination of closed protocols, reliance on a company that might vanish overnight (and has apparently in recent times threatened to terminate device support for non-licensed implementations!) makes me wary. What if the double their costs? Triple them? They've already massively increased their one-off price.

 

I've burnt the time with foobar->USB; bubbleupnp with openhome proxies and serviio and bad DLNA implementations; cmus; and a whole lot more. I've found mpd is the least irritating and doesn't attempt to change the music on the way through. When I find something better, I'll be sure to speak up. 

 

mpd anecdote: I patched the dedicated music playing host on my desk system last night. When it came time to reboot, the music stopped, the machine rebooted in about 30 seconds and the music started again, right where it left off. Even patching is less painful!

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

No such thing, mate! Well, no such thing as a typical household where the stereo costs more than the average car. Hah.

 

That's why it always has to start with requirements and end with requirements.

Maybe I have lept to specification too soon.  What requirements would you suggest a typical household with say 4 occupants/users for average use plus the desire for optimal ethernet for audio?

 

Take a stab, even an educated guess.  Get the ball rolling.

 

Let's not get bogged down i  details of defining 'typical' and 'average', there probably oodles of stats to guide that.  See nbn beside for instance.

 

11 minutes ago, PCOWandre said:

I'd again point to a switch replacement to something managed as bit of general good network housekeeping

What benefit would a managed switch provide compared to Ubiquiti EdgeSwitch 10x I use?

 

13 minutes ago, PCOWandre said:

not seeing a NAS called out in your path

No NAS. Antipodes advice was SSD is better than NAS.  Can you please clarify your question?

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

The Audio hobby certainly is prone to hyperbole.  The problem is, something seems to happening between the router and the DAC (inclusive of those devices) that can influence sound quality.  I’m not saying I know what is happening, but it’s a real thing.  The message here to “networking experts” is can you help us understand where the the network might contribute to changes in sound quality? That way we can all benefit, and make more discerning choices that reward the true engineers over the snakeoilers.  I think @rmpfyf tries really hard to do this.

 

(Warning: meandering rant ahea)

 

Sure, that's because I'm an engineer that for a good while there had life get in the way or more audio purchases. So I got into playing with PCs because it's free asides from the time, and the differences became good. A free kick is enjoyable after all, and it was actually quite fun to have friends over to see if they could hear differences. 

 

I used to have to recompile Linux kernels for my day job. I'm not a computer engineer, but my former field of work requires very long, complex computational work and if you could get another few percent speed out of the kernel you could finish a very long simulation at a more reasonable time, and start the next one before you went to sleep at night.

 

With respect to audio the more and more I played the more you observe how externalities influence playback. Eventually one builds tools that characterise some of the phenomena being heard, and the research goes into adjacencies that affect and interact with the sole thing you care about... playback!

 

I was able to understand a good bit more about the effect of networking on the PC, about power distribution around a PC and how that affects things, and frankly about what we can do in design to make these lesser or non-issues. 

 

I'm resolutely assured by a good friend that a PC CPU is a sh**e thing to make an audiophile box out of without a degree of taming that no one has really attempted. The friend in question is a former chip designer at Intel who had a good chuckle at the linear power supply for the PC -whilst it's directionally correct, said he, he pointed out the (very) significant fast-response switching power supply on a motherboard that takes that good work and makes a good mess of it, and we went into all sorts of science around design tradeoffs. We pulled out a variety of motherboards around the house and I learned a lot about power rail design and the effect on cycle times. It's tricky to design a PSU for minimum noise when most CPU power sources are two phase for low-power CPUs - the power draw has to be very low for this to achieve a 'noticeably cleaner' in terms of timing variance (we now do this with 6W CPUs) or the CPU power rail has to have a decent phase count, a favourable board layout and a large, low-noise and fast power supply hanging off it (hello Taiko). This is one - small - example. (I'm still waiting for that guy to introduce me to a BIOS designer mate of his). The expertise inherent is well beyond me though it's a fascinating discussion.

 

A good portion of sensitivity to upstream crap concerns the player. Not all playback software is the same, far from it. There are some very basic differences, for instance, in how various players deal with file format changes to what you end up with at the end (in my case USB) device. Yes, there are payload differences in playing back FLAC or device-native formats. WAV is not a device-native format but it can offer less computational work. Yes, these can be audible. 

 

Fundamental to it all is that you're using a device dealing in packetised data to generate a reliable, tempered stream with ideally perfect periodicity. Which is impossible. The buffers are there for the packet to work, they don't guarantee perfect periodicity at any rate. Periodicity of any downstream function is as good as the clock source - not the buffer - if the buffers aren't empty. Changing clocks in your PC is surgery so all we have left are software means to cut down the interruptions, and because we have packets and buffers there is no need for uber clocks to ensure the data gets there. I've seen a few people on these forums say 'rah rah buffers exist end of argument' though this is quite incorrect. It's not what they're there for and the effect of solely having a buffer present on jitter is very poorly understood in these arguments. 

 

The best way to fix all this is to buffer the stream downstream of your PC with isolation, mega buffers and mega clocks. This works so long as the device shuttling data to your buffer is not the same device also responsible for getting data from your PC or streamer. Usually they are so there is some sensitivity to upstream periodicity - this is why we have async USB which works best timed to some multiple of the output stream. So yes, there's a cascading effect of sorts, but a downstream buffer working off a relatively-well-tempered PC can do a great deal and it certainly is possible to design well at various stages enough to make differences imperceptible. Judging by comments here it's not commonly done, however.

 

You can of course get a PC to run so fast, so lightweight, so buffered and with such tuned priorities that the necessary audio data is there always in time as limited by the resolution of the PC's timing accuracy. This is what @PCOWandre, myself and others here do. The 'so buffered' and 'tuned priorities' parts here count a lot because - assuming we're not dealing with cabling bringing in any noise enough to play with power-based timing performance - if you can have your CPU having less of a critical look at your network whilst it's playing music, and you've made the task of playing music very easy and under-stressed whilst having configured the system for maximum timing accuracy, then I don't think fancy network hardware (which can only affect this stuff indirectly) can contribute anything beyond negligible. Maybe conducted crap through the port though run optical and you're done with that much.

 

The only off-the-shelf OS I've seen take care of this is Snakeoil OS, and even then it's a user-must-configure thing when last I checked. I guess it would be possible for this community to write some scripts that attempt to automate the process though it's not trivial and some understanding goes a long way.

 

1 hour ago, dbastin said:

What specification would you suggest for best audio outcome in a typical household?

 

Your experiences would suggest there's a performance sensitivity to conducted noise. Your GigaFOIL is a fancy optical isolator.  I'd wager many people would have a similar performance sensitivity as usually the last leg comes out somewhere in the vicinity of a lot of equipment flippin' some serious current and EMI. If you can't fibre all the way, run to something that cleans whatever up and then a very, very short lead - not more than 0.25m - into the endpoint. UTP unless you're treating the shields properly, Blue Jeans on 10GX would do fine. Ideally it'd be infinitely short though you've also got to deal with whatever the last device gives off.    

 

Get the number of packets down. Subnet it, bigger packets if your network can support it. If not you'll need a smart-ish switch/router. 

 

Get the phase noise of the packets down reasonably. Your Ethernet source may clock so poorly but the maths for lower frequency from a same clock source is well known, an 100MBps is fine for most. 

 

If you've a long shielded cable in play, treat the shield right or run some isolation near to source. 

 

They're the basics. Depending your equipment you may or may not be sensitive to each but they are each directionally correct. 

 

@PCOWandre's response came as I was writing this next bit - I would prefer a big buffer in the playback device - played completely from RAM - tuned affinities (get the NIC, playback thread and output device affinities well separated) and the file converted to the transport's native format prior to playback. That's not WAV, usually it's some PCM variant. If your answer from here is 'Roon' then there's not really much you can do. It is indeed convenient. I'd go $300 upstream if you were a Roon user that were able to invest in I2S/stream reclocking instead.

 

You have my views on AES67 for idealism. I could make an awesome 2-PC solution if that worked, with the latter on playback at silly low power and a Xeon beast upstream doing upsampling and filtering for shiggles (I have no idea why people would pay whatever a Taiko costs for an all-in-one).

 

50 minutes ago, dbastin said:

So, I'm not sure my experience with ECTs aligns with this.

 

The effect of dampening on ICs is well known, and I've no reason to doubt your experiences... though a more elegant solution would deal with performance sensitivities in a way that didn't necessitate your cracking open cases. 

 

Someone want to hot rod something?

 

I've got a bunch of Rakon Stratum 3E OCXOs - they're nicer than the stuff Paul Pang puts in his Netgear items (he does other stuff to though a doing some new clocks is part of it). 

 

They are 25MHz items, which is what you'll usually find in a switch or NIC. If someone wants to hot rod a switch and can build a power circuit enough to replace what's usually in a switch - post the process and results in this thread - I'll happily contribute an OCXO. Might even have a spare Mikrotik here somewhere too to play with (don't get excited, it's a baby without fibre). 

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

    No registered users viewing this page.




×
×
  • Create New...