Mosaic does not connect to Bartok

I’ve had an interesting question PM’d me overnight and I thought it was one that stood answering here…

The question was (paraphrased) “I notice that you haven’t replied on the forum post whether there are any known problems with <<the_network_kit_the_OP_is_using>>, is there a reason why and why can’t you just say what does and doesn’t work and what to buy so that your kit works correctly?”

…and that’s a REALLY good question with (unfortunately) a long and knowing me kind of rambling answer so I wanted to answer it here and if anyone has any questions on any of it I can then address those.

So, if I can lay down a little bit of groundwork, I think I’ve mentioned elsewhere that a piece of kit that is on a network doesn’t and can’t SEE anything else that is on the network, all it knows is what data comes in on the Ethernet port and what data it throws out of the Ethernet port.

As far as a device connected to a network is concerned it’s very much a case of “sitting in a windowless room with nothing but a door that opens onto an infinite black void” - you can shout a message out through the door and you can hear messages shouted back (which are all in exactly the same voice, this is important) but other than that you have absolutely no idea of what is going on outside that door.

A network device only ever gets messages that are passed on to it from the piece of kit it is connected directly to - any messages from elsewhere on the network are passed along in a kind of “Chinese Whispers” fashion until you receive the message via the bit of kit you are connected directly to (but unlike Chinese Whispers the messages stay intact - they don’t degrade from one hop to the next) you never talk directly to the bit of kit that you are messaging … Mosaic never talks to the Bartok, Mosaic (well, the device that it is running on) sends messages to the wireless access point, the wireless access point sends the message on to the next device in the chain, that then passes it on again and that repeats until it finally reaches the Bartok - they are never connected directly, even if they are “connected directly” via the IP address.

Anyway, let’s kick off with the broadest question in there - “…what to buy so that your kit works correctly?” …

There’s a really simple answer to this, and unfortunately it’s also the most annoying answer from your perspective as readers, which is “whatever kit you like as long as it works correctly”.

Ethernet as a defined is MASSIVELY reliable and resilient, whether you view it from the physical perspective, the electrical perspective or the communications protocol itself it has been picked apart and honed for the last 50+ years by people who bring a level of geekiness to their respective tables that would make most HiFi tweakers sob in disbelief.

Everything that we (and every other streaming audio manufacturer that I am aware of) do is totally by the book and the agreed and documented Ethernet protocols (this is generally enforced by the libraries of code that all software developers use nowadays - no-one in their right mind would “roll their own” libraries and if they did then they’d not be allowed to just use their own libraries of code on any kind of commercially available platform) and so as long as everything else in the chain between any two devices on your network properly support those documented protocols then it all “just works” … this is the situation that we all like and I’ve not come across any streaming audio service / provider / platform / manufacturer that goes rogue and does something outside of the Ethernet specs.

The problems start when bits of networking kit either don’t implement those rules for protocols correctly (perhaps because they’re using hardware that isn’t capable enough to do so or because they’re doing things in software / firmware that they made mistakes in coding) or the kit is configured incorrectly (such as if you’re using commercial grade managed switches that are configured to filter out UPnP or IGMP traffic that might be used on a consumer network but maybe wouldn’t expect to be used on a commercial network).

Very often things like ISP routers will fall short here because on the whole an ISP supplies a router so that their support staff know what they’re going to be dealing with and then they can support you more easily - their support guys that you get will generally not know much (if anything) about networking and will just be there reading from a template of questions and answers. An ISP is primarily there just to get you online as cheaply as possible and if they can save a few quid on the router that they give you as part of your bundle without causing too many headaches then they will - they are not there to provide you with a complete and resilient network.

Frequently mesh networking solutions will also fall foul of things like broadcast network traffic as that can end up with broadcasts being picked up and re-broadcast (which can end up creating massive firestorms of repeating traffic) unless they are carefully designed and coded to handle that and - unfortunately - within the consumer arena then it is often the case that in implementing these systems things either get missed in testing or get poorly implemented and again issues can then occur that weren’t seen in testing.

Even network switches - which should be simple enough - can fall foul. I know of several “audiophile” Ethernet switches (I don’t think they’re current any longer so I’m not going to name and shame) that were based on existing commercial grade managed switches where the programming was such that some things simply didn’t work “right” … in one instance a switch that had been set up to have designated / dedicated low noise “audio” ports and designated / dedicated high speed “network” ports and if you were using Roon with the Roon Core on the “network” ports and any players on the “audio” ports then Roon would simply break and be unusable - this is why we say to use unmanaged switches because the offerings from manufacturers such as TPLink and NetGear have been used in literally hundreds of millions of networks and they simply “work” and because they have massive economies of scale they are also cheap too.

Network cable specifications are also really tightly defined so as to ensure known and consistent characteristics over long lengths and using a cable that doesn’t adhere to those specifications can also cause problems with data integrity.

Now, we don’t recommend buying specific routers (or other network devices) because generally consumer grade products get replaced very quickly with new models, firmware updates take place, things get fixed that used to be broken and things get broken that used to be working and as soon as we make any kind of recommendation for a specific piece of kit (or a recommendation against a specific piece of kit) then it ends up becoming “lore” and updating that as time or scenarios change becomes really difficult …

To give you an example of such lore - you used to need to install a custom windows driver for playback of 32bit/384kHz audio via USB as Windows XP / 7 / 8 / 8.1 and even early Windows 10 didn’t support USB Class 2 audio but since 2017 Windows 10 (and all versions of Windows 11) support USB Class 2 audio and don’t need that driver so we no longer host it for download but so many people still go hunting for it and install it because they’ve either seen it somewhere or been told it by a dealer even though it isn’t needed (and can cause problems doing so) and we even specifically say that it isn’t needed in the manuals…

4 Likes