Usability Issues with Tidal

If the router in is an actual Cisco router running some iteration of IOS, its not likely and ideal router for home use. The cost of those devices are far beyond throughput and the ability to support a vast range of protocol and service and an endless level of configuration flexibility. For most typical home networking needs, they will be outperformed by devices that are geared for the average home user. I work on their ISR, ASR, CSR, Nexus, and Catalyst series throughout the day and except for the VM iterations, I wouldn't run any of them at home. Even with the VM iteration, it simply has features I have little use for at home.

They did have the small business line with Linksys during their ownership, but that was no more than in name. Better products were to be had by other vendors at that tier.

WiFi, even a decent unit, will have a large number of factors affecting performance. With the right set of tools, you can resolve many of the issues but some are not feasible to overcome without significant cost. Wired Ethernet will nearly always have a step up over wireless in nearly every scenario. Not always an option, but creating a test run is at least the gold standard. If there is a perceived sound quality difference, my best guess is that processors are working on error correction via TCP that address packet errors over the WiFi network. While all the data comes through, some latency through player may be created of no TCP offload processor exists that handles TCP error correction.

The Bluesound Node 2 is basically a variation of a Rasberry Pi3 like IOT board with some customized options. You're really paying for the software development over hardware. Its best use might be a transport device, but I couldn't say if it has a jitter prone output. 

Yes, Meraki was purchased by Cisco and its part of its SDN portfolio and is not a core Cisco product. It doesn't even have any of Cisco specific developed protocols that make them unique and has somewhat independent development.

I wouldn't discount on having impact as it contains features that are not typical for the home users. For example, it offers an IPS solution that is running Snort, and dependent on the rules being used, could impact web streaming services. The content filtering isn't likely a problem since those are quick to process and cached to some degree. The AV/Malware scanning options will also significantly impact its performance. If this device is being used in conjunction with a VPN tunnel, the typical AES encryption method used for those transfers could very easily eat up the CPU. A professionally configured unit to myself just means more advanced features could be enabled, thus putting a greater load. You really couldn't tell until you opened up the Meraki Dashboard and reviewed the settings. But if those features are not in use, the sytem should have more than adequate power. 

Based on what your comments about the sound though, I would agree with returning the Node2. Jitter issues will manifest themselves in very different ways depending on the device. Some devices will buffer any input to mitigate source jitter issues and others could be significantly affected. PS Audio DSD series has such buffering solutions in their product. They might have called it 'Digital Lens' at some point. Most modern DAC's today do buffer incoming data as they simply anticipate users will potentially see this out of some source devices.

As for why DAC's have few Ethernet connections, its more to do with continual changes in streaming standards than anything else. It means continued support and updates for client devices as new version of DLNA, Airplay, or Roon RAAT may be needed ongoing. Its a hard to quantify cost over the expected life of a component. Remember our audio components due have a longer shelf life than many consumer electronic devices users buy today. With that, many designers feel that an external transport solution might be best for something that will likely change once if not more in the expected service life of the DAC.