- If at all possible, use the 5 GHz rather than the 2.4 GHz band. The 2.4 GHz band has the advantages that inexpensive or old Android phones cannot receive 5 GHz and that the 2.4 GHz band penetrates walls better and has slightly more range. But 2.4 GHz has numerous deficiencies. First, there are only three non-overlapping 2.4 GHz bands, which contribute to the band being crowded. On top of that, there are numerous other devices using the same band, including wireless phones and microphones, garage door openers, and microwave ovens. Only other Wi-Fi signals will show up if you use a basic Wi-Fi scanner, but all of these devices interfere. Bottom line, 2.4 GHz has way more “pops and clicks” than you will hear on the 5 GHz band.
- On 5 GHz use a 20 MHz wide channel. Going wider to 40 MHz or even 80 MHz will not make the system faster or increase capacity. What it will do is give more opportunity for other transmitters to interfere. Essentially, a wider bandwidth is just a bigger target.
- Advanced Wi-Fi access points have the ability to jump from channel frequency to channel frequency so as to try to find a quiet channel. This is perhaps OK for the first hour or so of operation, but if it doesn’t settle down, it will be a problem. Every time the access point hops to a new channel, you will hear it. If it is hoping every 20 seconds (not unheard of), you will hear clicks every 20 seconds. Make sure that the access point algorithm settles out after a reasonable time or just do a manual scan with a Wi-Fi scanner (there are great free ones on Android), find the clearest band, and set the access point to that channel. Similarly, if you are doing this, there is no need for the Access Point to do its own scans looking for better channel frequencies so you can turn that feature off.
- Generally speaking, if you are going to get acceptable performance, you want your signal to be at least 20 dB higher than that of any interferer. A Wi-Fi scanner helps here.
- Watch out for data limiting by the Wi-Fi system. For public Wi-Fi’s it is often considered best practice to limit the data rate on a per-phone basis. A downlink throttle of 3 Mbps is not uncommon. But some Access Points interpret that limitation as meaning different limits for different classes of service. What we found was that a 3 Mbps limit actually translated to a VoIP (Voice over IP) limit of 125 kbps. Our system typically uses 140 kbps and tags the data packets with QoS (Quality of Service) tags appropriate for VoIP, so they were throwing away a lot of our packets. This was very audible. We ended up specially setting up the compression so that the packet rate was below 125 kbps and the audio cleared right up. We can do that for you if necessary.
- Speaking of QoS (Quality of Service) and ToS (Type of Service), we have the ability in our Cloud Server to set the QoS tags. The most typical are 0xD8 (today’s default) and 0xB8. For these to work WMM must be turned on in the Access Point and, ideally, QoS turned on in the switch/router. Without this, the priority of the audio packets drop and this means more hiccups in the sound.
- Don’t use range extenders, mesh networks, or multi-hop Wi-Fi systems if at all possible. Increases latency, variance and audio hiccups.
- Because of our comments on the noise issues with 2.4 GHz, on one hand, but the fact that some (mostly older) phones cannot handle 5 GHz, on the other, many people use dual band access points. It is worth steering the 5 GHz-capable phones to 5 GHz, either automatically, which some access points will do using “band steering,” or explicitly by having different SSIDs for the two bands and telling people to use the 5 GHz one preferentially.
- Sometimes the easiest thing to do is just let the system run for a while. The system contains algorithms to automatically adapt to the network traffic characteristics and as it learns, it does a better job of minimizing the pops and clicks.
While we are on the general topic of audio quality, it is worth saying something about the system architecture. We have optimized the system for minimum latency. Contrast this to, for instance, Apple who optimizes iPlay for fidelity. To do that they retransmit lost packets, re-order out of order packets, etc. But the result is a lot of latency, 2000 ms in their case. Our latency is only 40 to 90 ms. But the tradeoff is that ours is not an audiophile’s system. The bandwidth and compression is fine, but there are lost packets that are not recovered (because we don’t have time) and these are audible if you are listening for them. It is not unusual to hear a pop or click every minute or so even in a well-tuned system. We are constantly improving our adaptive algorithms and making it better, but know that there is a tradeoff and we are on the minimum latency, best lip sync, casual listening side of it.
