The post Nine hints for better, cleaner WiFi audio streaming appeared first on ExXothermic.
]]>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.
The post Nine hints for better, cleaner WiFi audio streaming appeared first on ExXothermic.
]]>The post Balancing bandwidth considerations appeared first on ExXothermic.
]]>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.
The post Balancing bandwidth considerations appeared first on ExXothermic.
]]>The post Load testing WiFi access points appeared first on ExXothermic.
]]>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:
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.
The post Load testing WiFi access points appeared first on ExXothermic.
]]>The post Soft gain adjustments appeared first on ExXothermic.
]]>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.
The post Soft gain adjustments appeared first on ExXothermic.
]]>