StudioLive RM32Ai and RM16Ai Mixers & UC Surface with QMix Ai
4 posts
Page 1 of 1
|
I ran into an issue last week and determined the cause and a reasonable workaround, but I figured I'd mention it here in case it benefits someone.
I mix a worship service and ran into a problem with our RM32AI crashing: no longer communicating with CS18AI control surface, QMix on tablets, and even the "Mute All" button on the mixer no longer responded. It was happening near the beginning of the pre-service practice before the band started playing, and it happened twice in a row on the same morning. Between crashes we'd have to power cycle the mixer. We eventually figured out that it was caused by several people connecting QMix UC for Android to the mixer at the same time. After service I took the 6 identical tablets and set them up side-by-side, powered on, connected wifi, started QMix on all of them, then clicked the mixer on each to connect and determined that when 2 or 3 were connecting simultaneously I could consistently reproduce the crash scenario. If I connect each in turn, waiting until the "Me Wheel" screen appears before moving on to the next, I could prevent the crash and things worked as expected. Equipment running at the time of the issue: RM32AI v9244 CS18AI v9203 MOTU AVB switch 6 Amazon Kindle 8 6th Gen Fire tablets (OS 5.3.3.0) (Google Play Store side-loaded in order to install QMix) QMix UC Android 2.0.1.42157 Mac Mini (late 2009) via firewire for recording (Capture 2.3.1.42749 is installed but was not recording or even started at the time of the issue) TP-Link AC1900 wireless router (only the tablets used wireless at this time; a Windows 10 laptop with UC Surface 2.0.2 is eventually used but not powered on at time of issue) On a separate note, our experience with QMix on the Fire tablets has been mixed. The allure of the Fire tablets is that they're fairly fast and inexpensive (~$80 during sales). It definitely works and is a serviceable solution for us, but it hasn't been as smooth as using it from an iPhone.
Cheers, Jonathan |
|
I can't believe there haven't been more responses to this.
I had a very similar issue with a new-to-me RM16 last night. This board worked fine until I had 4 people tied in with Qmix-UC to control their mixes. The board started freezing up and kicking people out. I was running UC Surface on a win7 laptop and my presonus systray icon repeatedly threw up limited connectivity errors. The Surface GUI was hanging up and not responding to controls, the board itself was showing symptoms of freezing via the input lights staying lit even when the band had stopped playing. The end users trying to run their own monitor mixes were also getting kicked out. I could power cycle the board and things would work fine for about 2 minutes but once the band started playing again, things would become laggy to the point where it would lock up again. I made three changes and the board worked fine after that. 1. Gave the board a static IP address 2. reduced the sample rate from 48k to 44.1 3. had everyone else close their Qmix-UC apps Based on your post, I have to assume it was the multiple 'monitor engineers connected' that was causing the issue. Sadly, I'd read in reviews that the Presonus board has no issues with multiple connections, unlike the behringer x18 which has shown bugs present when having multiple techs connected.. I would love to see more information on this, and hopefully a fix. |
|
I think your issue is a bit different from the one I described; we successfully run 5 Q-mix connections, 2 UC Surface laptop connections, a CS18AI connection, and record to a mac without issue every Sunday. The one I was describing was a hard freeze and crash when connecting multiple Q-Mix connections at exactly the same time; by that I mean the connect step where you select the mixer in Q-Mix. If I staggered those to connect one at a time I get all the Q-Mix connections with no issues. It still happens in the latest firmware, but it's not a high priority fix as it's pretty rare for most people and an easy workaround once understood.
The time I have seen something like you are describing -- intermittent problems that get worse until it crashes -- was when we had the latest firmware recording via firewire to an old mac mini that was no longer capable of updating its OS. There would be severe lag in Capture on the mac that eventually became lag in UC Surface on the laptops and in the Q-Mix tablets, eventually resulting in short freezes and a crash. We worked around that by reverting to an older mixer firmware version and Capture version. My suggestion would be to make sure everything is on the latest version -- certain mismatches between versions can result in problems -- and test. If you still have the problems, perhaps an older mixer firmware might be worth trying. We're on an RM32AI and not a 16, but we're running a 48K sample rate with a lot of connections and working reliably. We seemed to have some recording/lag issues with the latest firmware (13731) so we reverted our mixer to 9244 along with rolling back some other software versions and things are working. If it helps, here is our setup with versions. Everything except the tablets/laptops are wired ethernet unless otherwise noted. Once we rolled back versions to get past the recording performance/freeze issues, we work consistently.
|
|
I think our issues were pretty similar (except I'm not running Capture).
This board worked absolutely perfectly the first time I used it at our band practice, with just a tablet and a laptop running UC Surface wirelessly. The second practice, I started getting the band members connected with their various phones to the QMIX UC app and that's when the board started locking up. I don't recall whether their connections were made in a series or if everyone started connecting at once, but twice, I power cycled the board and it seemed to work fine until the band started playing and it was passing audio, then it the UC Surface interface on my laptop would start lagging more and more over a couple of minutes until it just kicked everyone out. I know the board was frozen because the input lights on the board were still showing signal (lit up) even though the band had stopped playing. it's almost like it was a combination of being overwhelmed by the multiple QMIX UC connections and having to process audio (DSP/Dynamics)... very frustrating. I can try to stagger the QMIX UC connections tonight to see if slowly introducing new connections makes a difference. |
4 posts
Page 1 of 1
Who is online
Users browsing this forum: No registered users and 63 guests