As it has been mentioned once or twice already, be very careful with wireless products. Alas, not a 100% solution that works in ALL circumstances, but the following guidelines can save you customer troubles (I sat for a few years as observer on the 802.11 committee and this was a common topic).

1. As much as possible support BOTH 2.4 and 5.8 bands; surprising how they get into different and unpredictable types of interference with other products regardless if you use Wi-Fi or non-Wi-Fi protocols [I have point-to-point audio relays at 5G that kills wi-fi networks and were therefore returned to manufacturer with 'carefully' worded explanations]

2. As much as possible, use 802.11 direct (not the embarrassing driver available for free in Linux boxes). "Miracast" is an excellent example of streaming protocol that works WITH a wi-fi network and not against it. That way, collisions and network thrashing can easily be avoided.

3. Exploit the fact that you can have as many wi-fi connections as you want with a wi-fi adapter. The limitation of ONE connection comes from lazy driver remapping of existing 802.3 networks (LAN) to offer TCP/IP over wi-fi. Not sure about open source linux drivers that can do that, but Windows has removed that limitation since Windows 7 (not made very visible to users to avoid confusing them, but it's there anyway and they use for fast media streaming).
==>> This means that, there are NO technical reasons why the AA cannot have BOTH hotspot mode and network mode at the same time... apart from possibly challenging linux driver work which may or may not be outside the existing skill set of your software development team.

4. If you are using TCP/IP network (802.3 artificial mapping of 802.11 associations), use UDP over TCP for streaming. Losing ONE packet is nothing (inaudible) compared of the stuttering caused by repeating entire sequences because of TCP re transmits of last 6-7 packets which can cause very audible "pops" or worse, stuttering.


See Mojo's signature