Why Did The M32 LOCKUP and STOP AUDIO? 🤯
HTML-код
- Опубликовано: 8 сен 2024
- Have you been mixing wirelessly and your console just locked up? Have you experienced blips in connectivity between an iPad and your console? Let's take a look at the networking details that cause a fellow mix engineer some trouble when he was working a recent show.
➡️ Need One-on-One help?
Fill out my contact card at sound.allamhou...
➡️ Find the cables and other products I recommend here
amazon.com/sho...
I haven't run into this issue since we restrict the devices that can connect to the main M32 Console router by not broadcasting the SSID. We usually have just 2 tablets running MixingStation for adjusting while on stage during sound checks and setup. All bands that have performed at our venue that have IEM always show up with their own RackM32 and dedicated router which they connect to all their iPads to, then they just split and feed into our DL32 stage box.
Thanks for sharing this with everyone. Restricting does seem to be an efficient way to add some control into the network setup.
@@AllamHouse The other reason for hiding the SSID of the M32 Router is that during performances/shows you would be amazed at how many people scan and attempt to connect, there are some nefarious people who attempt brute force attempts to connect. . This happens even though we have a free public access SSID available.
Not sure about the stale/zombie TCP connections theory since the M32/X32 OSC protocol uses _UDP_ on port 10023, and subscriptions to meter/fader updates only last 10 seconds unless renewed. UDP is a connectionless, best-effort protocol and lost packets are not retransmitted, so I can't see how poor connections will do anything except cause some console metering or fader position updates to be missed.
There are many variables that would need to be tested and the router is certainly one of them. Thanks for sharing the comments with the community.
How about another explanation: his sync between mixer and devices could be set to "device -> mixer" instead of "mixer -> device", so every time so the device loses sync or has to reconnect to the mixer, the mixer is out of sync for some time
I do like this idea. My only thought is that the iPad app doesn’t provide the same “device > mixer” that the X32-edit computer software does.
@@AllamHouse you're right !
I've accidently pulled a USB stick while the red light was on and the console locked up. That was the only time it happened to me
YeH, that is a common issue with the console. Not really sure why that locks it up, but certainly causes problems sometimes.
Sure it's not an iOS issue? Or perhaps a router issue? A lot of guy are running like ANCIENT Wifi routers cause they "work". Sounds like more like the router is not figuring out the iPad has dropped the connection, and is keeping it open while the iPad has lost patience with the router, perhaps it was on 5ghz and moved to 2.4ghz, and proceeds to open a new connection.......I'd get a AC or AX (Wifi6) router and see if that fixes the issue.
Yeah, I don’t have any more information than what was in the post, but you do point out some great items that should be tested as well. Thanks for sharing with the community.
@@AllamHouse I mean, some of these audio guys on Reddit and Facebook are still using Airport Express units, which haven't been made in 6 plus years now. I'd make sure the wifi for your rig matches what your iPads have. If it is Wifi with ac, then have the router do that. If it is ax, get an ax router. Much better to keep things current than to have "well it always worked" excuse when stuff craps out. Oh, and have a BACKUP wifi router for mission critical things or if you didn't bring a laptop that you can cable into the x32.
So what would be the Fix or solution if you ran into this? Thanx
There were some great comments added on this video that you can check out. The general items are to use a dedicated network for the setup. Also, restricting the connection to your known devices is an extra step of security.
Having audio stop being passed because too many tcp connections have been opened sounds like bad programming to me, it should simply refuse connections rather than have audio fail.
I agree it does seem like an odd result to have based on faulty network interaction, but that's one reason I felt it valuable to discuss here in the community. Hopefully others won't get stuck in a similar situation.