ExXothermic

Nine hints for better, cleaner WiFi audio streaming

Lance Glasser — Thu, 27 Jul 2017 01:35:20 +0000

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.

Balancing bandwidth considerations

Lance Glasser — Wed, 22 Feb 2017 19:46:49 +0000

When looking at a streaming WiFi audio system, there are several potential bandwidth bottlenecks.

The Ethernet Switch
The Venue Server
The Wi-Fi Access Points
IP Address space

In our last technical blog, here, we looked at the Wi-Fi access points. Access points must be added to reach the total number of clients (smart phones and tablets) that will be listening at one time.

Doing some quick calculations on data rates and bandwidth, assume 150 kbps for the communication to each phone and a 50% load capacity on the Ethernet, then 100 baseT (100 MHz) Ethernet can support about 300 phones and Gigabit Ethernet can support about 3000 phones, assuming no other significant traffic. It would presumably be best to use a cut-through switch for minimum latency, but as a practical matter, no one does this because of the cost.

ExXothermic has designed a range of systems that can handle different number of clients depending on the processor and network interface, starting with 150 client phones for the most basic offering.

Finally, one does need to get enough IP address space in the network so that each phone can grab one from DHCP. The usual netmask of 255.255.255.0, for instance, only provides for about 250 addresses. And don’t forget about the impact of DHCP lease times (we recommend 120 minutes). An IP address for a phone that has left the building cannot be reused until it is released.

The proper system deployment considers all of these potential bottlenecks.

Load testing WiFi access points

Lance Glasser — Thu, 16 Feb 2017 18:55:13 +0000

We have recently been load testing WiFi access points for use with WiFi audio streaming. We had a lot of questions on the results because the specifications of enterprise grade WiFi do not really address our special case. One one hand, they talk about bandwidth, but we have very small packets and are not really bandwidth limited. For instance, an 802.11ac access point with an 80 MHz wide channel could theoretically support 3000 phone. That is way too high.

And to maximize the quality of the audio, we set the bandwidth to 20 MHz. This minimizes interference with other WiFi devices as well as with other radios in the band. We do this because if one has high levels of interference, one hears the lost packets. Unlike a system like Sonos, we tune our system for minimum latency and best lip sync, which means we have no time to retransmit lost packets. In our system, one does not hear a single lost packet, but if there are several in a row, one does hear that.

On the other hand, if one looks at the specifications for the number of VoIP (Voice over IP) calls an access point can support, one gets a very small number, e.g., 30 or 40. That is too low. VoIP traffic is not synchronized and people can talk at any time. In our system, there is only one transmitter and it is handing out packets sequentially to many phones. In an ideal scenario, there are actually no collisions. So VoIP specs are too low.

We set up a measurement to emulate the traffic in our system. We had a source that handed out packets just like our ExXtractor venue server and programmed a second computer to emulate the smart phone receivers, each with a different IP address. Then we set up two access points in mesh mode and blasted packets from one to the other, with the source wired to one and the sink wired to the other.

What we found was:

Ruckus ZoneFlex 7982 worked well with 250 clients, but at 300 we heard drop outs. 200 clients seemed safe.
Ruckus r600 worked well with 300 clients, but at 350 we heard drop outs. 250 clients seemed safe.
Aruba IAP-205 worked well with 300 clients, but at 350 we heard drop outs. 250 clients seemed safe.

All of this was in an environment without any other traffic, but it was only using one radio. In practice one would use both bands but use band steering to send most traffic that can support it to the 5 GHz band. Interestingly, these numbers are about half the theoretical capacity of a 20 MHz link, so we are in the right ball park. We used gigabit Ethernet.

All of the devices we tested were Wave I type. Wave II could add additional capacity on 5 GHz to the extent that Wave II phones, such as modern Samsung phones, were used as clients. Thus a Ruckus r510 or r610 could be helpful in this regard.

Of course, there are all sorts of things that impact a real-world deployment, but this should give one a pretty good indication of what is possible.

Check out our blog on balancing the overall system bandwidth, here.

Soft gain adjustments

Lance Glasser — Mon, 22 Feb 2016 18:53:41 +0000

Version 2.40 of our venue server software introduced soft gain limiting for our gain adjustment function. This is for use in cases where the audio volume of a particular source is too low and must be boosted. The gain is adjustable in 6 dB increments. That is, every increment is roughly equivalent to moving twice as close to an audio source. The venue servers take in line-level inputs, but not all sources conform. Here are the gain curves that we have implemented. The soft limiting make the audio output sound more pleasant when over-driven.

The control is done most easily by our Cloud Server. Here are what the controls look like. “0” corresponds to 0 dB, “1” to +6 dB, etc., up to +24 dB.

Gain adjustment controls on Cloud Server