Hi Guys
I can probably give an insight into what’s going on.
I posted here about some testing we’d been doing gearing up for the release of OneMix:
https://iliveforum.allen-heath.com/topic.asp?TOPIC_ID=2279
What we do is send a small UDP message across the network from an iPad ( or any client ) to the mixer every second, then wait for a reply.
We then have a timeout, I.E if we don’t receive a reply to this small message within 10 seconds, we display the Lost Comms landing page.
We do this because if you walk out of wifi range and start pushing the fader up and down, you’re not actually affecting the mix, and worse if you come back into range, the buffered messages can be delivered all in one go – and make an unexpected big change to your mix.
The timeout was 10 seconds in V1.8.
After requests saying “10 seconds is a long time before telling me I’m out of range”, we lowered it to 5 seconds in V1.9.
You can then get customers like Jim saying, it worked previously, but since upgrading it doesn’t.
This is probably because of the lowered timeout.
As a possible solution, we could put the timeout back to 10 seconds, but also display a QOS warning far earlier, to give you guys a clue that you might not have control of the desk.
Any feedback would be welcome ?
All this is wrapped up in a slightly larger issue of router stutter / throughput.
The consumer grade access points we’d previously recommended behave OK in a single iPad / laptop environment.
What actually happens is when a client roams out of range the access point can stop passing traffic / stutter and buffer traffic while it tries to work out where the client has gone. Even if the traffic is UDP.
If you’ve only got 1 client connected, this doesn’t matter, but in a multi-client / iPad situation I.E OneMix, if one client walks out of range, all other connected clients will have their traffic interrupted… and potentially disconnect as Jim has observed – dependant on how long the roaming client stays out range.
This manifests as the packet loss you can see if you wirelessly ping across the access point, after a client goes out of range , as Frank has observed.
The solution to all this ?
We’ve been testing more “pro” access points, and have updated our Router Compatibility document to include the Cisco Aironet 126N.
https://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps10980/data_sheet_c78-593663.html
https://www.allen-heath.com/UK/CategoryDocuments/iLive_Router_Compatibility.pdf
This access point suffers from noticeably less stutter (consistent ping response), and quickly deals with clients which have roamed out of range, allowing other clients still in range to not loose communications.
It also has external antennas which can be remotely positioned for better wifi coverage at the venue.
To sum up, if you’re a single iPad user we can tweak the timeout back up, if you’re a OneMix / multi MixPad user, you might want to consider purchasing the recommended pro access point to give better throughput performance.
Hope this helps.
Andy
A&H
]. I can’t think of a way of pretending this is a feature, so yes it’s a bug! The pan does control the send pan, but its also been accidentally cross linked to the main pan. If your using an I/P split, and therefore the I/P is off to the main it wouldn’t matter, but otherwise it would affect it, and is therefore wrong !
