{"id":34033,"date":"2025-06-19T14:25:05","date_gmt":"2025-06-19T21:25:05","guid":{"rendered":"https:\/\/www.podfeet.com\/blog\/?p=34033"},"modified":"2025-06-22T18:09:51","modified_gmt":"2025-06-23T01:09:51","slug":"rim-demo-take-2","status":"publish","type":"post","link":"https:\/\/www.podfeet.com\/blog\/2025\/06\/rim-demo-take-2\/","title":{"rendered":"Update on Recording Remote Incident Manager"},"content":{"rendered":"

When last we left our heroes<\/a>, Chris Cooke and I were trying to figure out how I could record a video for her presentation at Macstock<\/a>. She\u2019ll be talking about how she uses a tool from Pneuma Solutions called the Remote Incident Manager to connect to another person\u2019s computer to provide them technical support, all through the use of VoiceOver on the Mac.<\/p>\n

Our goal was to capture video of the target computer (my Mac), along with audio of her voice, my voice, and VoiceOver. The problem we ran into was that any attempt to record the audio on my Mac caused a feedback loop to Chris where she would hear her own voice 3-5 seconds after she said something. It wasn’t possible for her to perform the demo with this kind of feedback.<\/p>\n

Eliminating the Audio Feedback the Easy Way<\/h2>\n

In my previous post about our attempts to record, I explained the incredibly convoluted process we developed that required 3 Macs, 3 Microphones, 3 sets of headphones, and one iPhone to achieve our goal. I sent the article to Pneuma Solutions along with even more details about the problem. A gentleman named Jack from the support team wrote back with a good question. My article explained that to record the audio from Remote Incident Manager, I was choosing to capture System Audio. Jack asked whether I could try capturing just Remote Incident Manager instead of all System Audio.<\/p>\n

I have the tools to do this, and after kicking myself for not thinking of it as a possible solution path, I set it up. My recording was being done with the screencasting software ScreenFlow from Telestream<\/a>. It\u2019s designed to record the screen, and I can add as many audio input devices as I like. But applications, like RIM, are not audio input devices. With the help of Loopback from Rogue Amoeba<\/a>, I can create virtual audio devices out of applications. This means that I can assign the audio output of Remote Incident Manager as an audio input to ScreenFlow.<\/p>\n

In Loopback, I added a new Device, and named it \u201crim\u201d. I used the plus button to add a new source, and from the Applications dropdown, I chose Remote Incident Manager. By default, when you add a new application, Loopback mutes it when capturing. This messes me up every time I do this, so I immediately flipped open the Options chevron and UNchecked Mute when capturing.<\/p>\n

\"RIM
RIM Virtual Audio Device in Loopback<\/figcaption><\/figure>\n

Once you create a virtual device, it now simply exists on your Mac. You can (and should) close Loopback and start to use this new device.<\/p>\n

In order to capture VoiceOver, it also needs to be added as a virtual audio device using Loopback. I did it so long ago that I entirely forgot that it wasn\u2019t normally exposed to applications for recording. When you create a new device and choose Application from the source list, there\u2019s a section entitled Special Sources. From there, you can choose Background Sounds, Finder, Siri, Sound Effects, Spoken Content, System AirPlay Receiver, or VoiceOver.<\/p>\n

\"Creating
Creating a Virtual Audio Device for VoiceOver<\/figcaption><\/figure>\n

Now that I have my two virtual audio devices, I\u2019m ready to set up ScreenFlow to record. Under New Recording, I selected my built-in Retina Display for the video, then the three audio devices: my Wave XLR mic interface, VoiceOver, and my RIM virtual device.<\/p>\n

\"ScreenFlow
ScreenFlow Ready to Record<\/figcaption><\/figure>\n

Now all I needed was someone to test with, and since Shawn from Pneuma Solutions had just emailed me, I wondered if he was online. I asked him for a play date, and he readily agreed. He launched Remote Incident Manager and created a Keyword. I entered the same Keyword on my Mac in Remote Incident Manager, and instantly, he was connected to my machine. He could navigate my Mac with VoiceOver, hear my voice, and I could hear his.<\/p>\n

Now for the moment of truth: to try recording the session. I told ScreenFlow to record, and he did not<\/em> get feedback on his Mac! We solved it! But are we sure that’s what fixed it?<\/p>\n

If you\u2019re a good scientist, you know that a good experiment minimizes the number of things changed. While we had changed just one thing on my end, we had no idea how his Mac might be configured compared to Chris\u2019s Mac, including what microphones and headphones and software she was using.<\/p>\n

But I could change this one thing back and have a good experiment. I changed ScreenFlow from recording just Remote Incident Manager to recording System Audio, and asked Shawn to talk. Within a couple of seconds, he said he heard his own voice reflected back to him. I flipped back to recording Remote Incident Manager instead of System Audio, and the echo disappeared. Now we have good experimental evidence of success.<\/p>\n

After we confirmed our success, I went into ScreenFlow and verified that I had 3 independent audio tracks and one video track. It\u2019s clear I\u2019ll need to do some work on the audio levels, but the experiment confirmed success.<\/p>\n

\"ScreenFlow
ScreenFlow Audio Video Tracks When Talking to Sean<\/figcaption><\/figure>\n

Demonstrating RIM in Zoom<\/h2>\n

A normal person would have hung up on Shawn at this point, but we got to chatting about why Chris and I wanted to do this. He explained that he\u2019s tried to present Remote Incident Manager in a Zoom meeting before, and it caused what he called a \u201cfeedback tornado\u201d!<\/p>\n

He\u2019s been a Windows user for years, but since Pneuma Solutions started supporting macOS, he\u2019s had to learn the Mac. He\u2019d played around a bit with demo copies of Audio Hijack and Loopback but didn\u2019t really know the tools. Well, I couldn\u2019t pass up the opportunity to teach a FOURTH blind person to use Rogue Amoeba software, could I?<\/p>\n

I started with Audio Hijack, and he very quickly caught on to the concept of the little blocks you drag into a grid, and why you\u2019d want some in parallel and some in series. But to fix his feedback tornado in Zoom, I suggested a possible path to success using Loopback.<\/p>\n

Let\u2019s say his co-worker Jack initiates a RIM session with Shawn\u2019s Mac as the target. Shawn joins the Zoom call. My suggestion was to create a virtual audio device using Loopback that combines three sources: his microphone, VoiceOver, and Remote Incident Manager. Using VoiceOver keystrokes while he listened to me navigate through Remote Incident Manager, I created this virtual audio device using Loopback. (I was kind of proud of myself for being able to do that!)<\/p>\n

Once I had the new virtual audio device built, I opened Zoom, and without going into a meeting, I changed my audio input settings to this new virtual source that combined the three inputs. I spoke, and the little meter in Zoom moved. I had Shawn speak, and again the meter moved. I had Shawn move around on my Mac to trigger VoiceOver to talk, and again, the meter moved.<\/p>\n

This isn\u2019t a complete experiment since I didn\u2019t get on a real Zoom call, but I\u2019d bet dollars to donuts that this would work for him without any feedback tornadoes. I left Shawn with the promise that if he ever wanted to play around with Rogue Amoeba tools again, I’d be glad to help him out. He was quick to learn, interested in figuring things out, and he laughed at my jokes.<\/p>\n

New Hurdles \u2014 VoiceOver Lag<\/h2>\n

A few days later, Chris and I sat down to record the demo with the new, simpler process. Now that I was recording just RIM and not the entire system audio, I was confident we could do the demo without the audio feedback to Chris.<\/p>\n

The good news is that Chris no longer experiences feedback of her own voice. The bad<\/em> news is that we had a whole new problem. Instead of hearing VoiceOver from my machine in near real time, it was taking 5, 6, to 7 seconds for VoiceOver to get to her! Imagine trying to do a demo where the video is 7 seconds behind.<\/p>\n

We disconnected and reconnected several times, but still there was this terrible lag with VoiceOver. My first thought was that perhaps Remote Incident Manager was somehow struggling with the amount of video being presented, as I had my external 32″ 6K display attached. I disconnected it, which caused a lot of logistical problems because everything routes through it, and finally just attached a second microphone to my MacBook Pro.<\/p>\n

This did not fix the problem. We disconnected the call and gave up for the evening, but continued to swap ideas over the next few days while we did more experiments.<\/p>\n

Chris ran a network speed test of her WiFi, and as expected, the speed was far less than if her computer had been hardwired. I suggested using Ethernet, but she hadn\u2019t ever connected that way on her home router, so she wasn\u2019t sure where to plug in. She called me on FaceTime so she could show me her T-Mobile WiFi router, and on the back, there were two open Ethernet ports. I was confused that there was no network cable going into<\/em> her router. She managed to focus her phone on the model number (which 98% of sighted people could never do), and I looked it up. It’s a 5G router using cellular, which I should have realized from the name “T-Mobile”. That explains why there was no network cable going in.<\/p>\n

She bought a USB-C to Ethernet adapter and an Ethernet cable, and hardwired her Mac. We confirmed that the interface order in System Settings \u2192 Network had Ethernet at the top. That gave her much faster speeds, but it didn’t fix the lag in VoiceOver coming back to her.<\/p>\n

I asked her to check her Activity Monitor just in case there was something aggressive running on her Mac, and we found that Carbonite was chewing up 17GB of RAM. But disabling it didn’t affect the lag in VoiceOver.<\/p>\n

I read online that a VPN could affect the Remote Incident Manager. I run Tailscale all the time, which is sort of a VPN, so I disabled it, but that did not fix the problem.<\/p>\n

Timing on Enabling of VoiceOver<\/h2>\n

I finally came up with what we think<\/em> was the root cause, but I hesitate to confirm since I’ve been wrong so many times before.<\/p>\n

Chris usually helps her blind students with their computers, who are already running VoiceOver, when she connects using Remote Incident Manager. Remote Incident Manager is designed such that the target machine doesn\u2019t need to be running VoiceOver to function, and since I’m sighted, I don\u2019t have it running when Chris connects using Remote Incident Manager.<\/p>\n

Without VoiceOver on my Mac, the RIM connection brings up a visual VoiceOver panel in the bottom left of my screen, but I can\u2019t hear<\/em> VoiceOver. If I can\u2019t hear it, that means I can\u2019t record it for the demo. What we\u2019ve been doing all along is as soon as Chris connects to my Mac, I toggle off VoiceOver, which kills that little panel graphic, and then toggle it back on to enable full VoiceOver on my Mac.<\/p>\n

After eliminating all those other potential causes of the delay, I wondered whether my toggling VoiceOver off and back on again had anything to do with it. We disconnected yet again, and for our final test, I enabled full VoiceOver before<\/em> Chris connected. She poked around on my Mac a little bit, and she said the 5-7 second lag was down to maybe a second, which she said she could live with. I think we found the root cause, or at least the predominant cause of the lag problem with VoiceOver.<\/p>\n

Video Production<\/h2>\n

We were finally ready to record. Chris\u2019s demo was to show me how to open a website in Safari, copy the URL, open Notes, write a quick note, select some of the text, and then create a clickable link to the website on that text. So her steps were:<\/p>\n