Agree that digital is usually bit perfect - it works or it doesnt- no in between noise.
However… Im reminded of the time I bought a new laptop and it crashed occasinally and one or two files got corrupted. So i generated a 1 gb file full of random data and made a copy. The copy had a few bit errors, so i took the laptop back. At which point i was told that i shouldn’t worry because it was only a few bits. I laughed so hard I nearly had an accident of the type i haven’t since i was a baby in diapers.
I don’t know how RAAT does multi-room so I can’t comment directly on your point.
However, I strongly suspect that RAAT does not rely upon packet timing to time align the different endpoints - doing so could not guarantee the 1ms alignment or better claimed by the Roon RAAT article that you quote. I have direct experience of this. I have tested a multiroon scenario where one endpoint was connected to the core with standard wired ethernet, and another was connected by WiFi - which also involved a ‘ethernet over mains’ hop from the Roon core to the router. This ‘ethernet over mains’ had packet transmission delays and jitter far exceeding anything you would expect from WiFi alone (packet transmission times varied between a minimum of 10ms and over 70ms (compared to sub 1ms for normal wired ethernet) within my home). The multiroom audio, worked fine and the audio from the two endpoints stayed in sync over a reasonably extended test period.
Before I retired, I was involved in a system that used PTP (Precision Time Protocol) to time align systems that could be separated by 3km or more to an accuracy of significantly less than 1us (micro second). This is orders of magnitude better than anything required by an audio system and I also don’t think that many Roon endpoints are 3km removed from the Roon core. If I was designing a system like RAAT, I would use PTP to time align the ‘starting’ of the stream and to keep the stream in sync thereafter.
Indeed. The difference between 1 and 2,147,483,649 is only 1 bit - but I would not be happy if £2,147,483,649 was deducted from my bank account when I wished to pay someone £1
Packets are not timed, of course, RAAT runs on TCP. What is timed is the overall stream from Roon server to Roon endpoint. Packet loss and retransmit caused by WiFi contention can be enough to disrupt that timing and lead the Roon server to give up on the stream. Bursty contention is the problem here, not latency or jitter.
Pedantically, I believe what you’re implying is twofold:
Roon can control the rate at which packets are sent from the server to any given endpoint
Any given packet, or set of packets, can include some form of time signature that informs the endpoint of when the packet(s) are intended to be played
#2 is probably a relative offset and I don’t know the implementation so I can’t say if this applies to every packet or to “key” packets and I also can’t say if RAAT leverages the presence of time signatures in the existing encoding or if they do it in a layer above.
@Wade_Oram started this thread by essentially asking “Why do people have problems?” He framed it in the form of “Why don’t I have problems?” but the actual question was “Why do others have problems?”
@Wade_Oram has mentioned “jitter” a couple times. I don’t think it helps to introduce this concept. Latency can be interesting but as long as latency remains within a window that Roon predicts when beginning to stream, it shouldn’t be problematic.
So, in simple terms, playback will suffer if too much data gets to the endpoint too soon, or if not enough data gets there. Overfill and underfill.
Unless RAAT is broken, and I don’t think it is, overfill is not the problem. Underfill is. As @Fernando_Pereira has already said, latency alone is not going to be enough to cause underfill. He posits that “bursty contention” can be the issue. I would generalize this beyond bursty contention and simply say that anything that causes signficant variability or delivery issues, beyond the predictable and consistent latency of a healthy network, is the issue. Generally speaking, wireless networks are far more susceptible to these sorts of issues than wired networks. You might be contending on the same frequency as your neighbor. You might be moving your endpoint around the house. You might be on a mesh network where backhaul is competing. You might be on a 2.4GHz network where the max throughput, in the best case scenario, is 600 Mbps and you might be trying to stream something that pushes hard at, or even beyond, that limit.
In my opinion, the best practice is:
Use a wired network
If you don’t know what you’re doing, buy simple, unmanaged switches from decent manufacturers like Netgear
If possible, put your core, endpoints, music server on the same switch
Don’t use your ISP-provided modem/router as your switch
Don’t mess around with subnets unless you absolutely know what you’re doing
Your controllers (such as your phone) can be on your WiFi network as long as they’r eon the same subnet as everything else
I’m not sure there’s anything else to recommend. Of course, I don’t remotely follow this advise that’s another story
Jitter is an overused term - audiophiles often use it in relation to the clocking of samples onto a digital to analogue converter device which, if not controlled to a sufficient degree, would cause audio quality issues. Many, myself included, believe that this is not the issue that it may once have been (although it will always be present to some degree). In any event, jitter in this sense does not pertain to the topic in question.
However, I used it specifically (and I have always been careful to be explicit) to relate to the acceptance of good packets into the DAC devices processing pipeline/buffer - which is completely different and does not have any impact upon audio quality provided that the packet is delivered before a buffer underflow occurs.
The talk about Wifi is all a distraction from the thread because my comments were made in response to @wormcycle who said:
In that context, the use of WiFi should not contribute to noise but, in the event of buffer underruns, it may cause other audio artifacts like pop’s and dropouts. In any event that issue with the shared bus between WiFi and USB on the RPi3 is also true of Ethernet and USB on the RPi3.
In response to this, my response specifically said:
and (bolding the releveant part for emphasis), in the same post - and the part previously quoted:
With that in mind, the discussion about the possibility of Wifi causing packets to be delayed to the extent that buffer underruns has already been addressed and to take the rest of what I said out of this context does not give a true representation of what I was saying.
Anyway, I was hoping, as @gTunes suggested, that this thread would lead a set of points of practise - emphasising and possibly even going beyond the Roon Networking Good practise article - that would help others in the future.
With this in mind, I think the key points in relation to WiFi are:
The share of the total WiFi bandwidth available to an audio stream must be sufficient (in order to be able to provide within-time packet delivery). This relates not just to the quality of the WiFi link (signal strength - data rate etc) but also the use to which is being put by other network components - quite possibly for purposes completly unrelated to audio.
Mesh Wifi may cause issues with audio streams as the stream is ‘handed off’ from one WiFi access point to another because either the endpoint is physically moving (e.g. a mobile phone being carried about the premises) or because it is on the signal strength border such that it is bouncing between two access points (I believe the better mesh systems emply mechanisms to prevent this from happing - but I have no experience so I can’t comment on how effective such mechanisms might be). At such time a delay may be introduced which could cause a buffer underrun.
Mesh systems can cause larger packet transmission delays when a backhaul (the network connection between WiFi access points) link is involved. This, on its own, should not cause an issue unless the system was already near to breaking.
In the case of Mesh Wifi systems, it might be worth mentioning that:
At least some Mesh WiFi systems have a mechanism that allows particular clients to be bound to a particular access point preventing the handoff issues - this might be appropriate for physically static elements of the Roon network (or that of any other Audio/Video streaming system) where the Mesh can not otherwise decide which access point should be used.
If possible, a wired backhaul should be used because this reduces the total amount of WiFi traffic on any one access point (It may also be possible to achieve the same effect with some of the modern tri-band WiFi systems if one of the bands can be dedicated to the backhaul traffic).
Mesh systems using a WiFi backhaul can make the ‘share of bandwith available’ smaller and thus cause problems because the bandwith of backhaul connection is shared by all of the access points in the system and may thus be more saturated than any one access point.
This thread can either be about a setup that would work potentially with no issues in networking, and minimal noise in the system, or it can be 100 pages discussing every aspect when wi-fi will or will not introduce noise: conenctions to DAC, positioning etc. Possinilities are endless. I am not saying it is not interesting discusion but maybe we need two threads. Roon documantation is very week on networking, every time an error is reported the support asks for entire network topology. To what level: internals of the packet switching implementation for a particular switch? Firewall configuration? Most of the time it is something in firewall or router configuration that affect RAAT.
Message to Roon: let mw take care of the network, just tell me the best configuration for RAAT.
