The following is a guest blog post, written by Greg Kopchinski, Waves Live & Install Product Manager.

Waves Audio is a Grass Valley Alliance member, an open digital community committed to providing a range of certified solutions for AMPP.

Mixing Broadcast Audio at 36,000 Feet

On my transatlantic flight heading home from IBC2022 in Amsterdam, I pulled out my laptop and started working through the dozens of emails that had been put aside over the past week. I had purchased the global  Wi-Fi plan and wanted to make the most of it while captive in the crowded economy cabin.

On the seat back screen was the flight path, and I watched as we passed over the last dry land and levelled off on our journey across the ocean. The altimeter displayed 36,000 feet, there was no turbulence, and my seat neighbors were dozing off after the meal service.

In the corner of my laptop screen my eyes were distracted by my IBC demo folder. Waves recently joined the Grass Valley Media Alliance program, and I had put everything I needed for our show floor compatibility demo in the desktop folder in front of me. For those who aren’t familiar, Grass Valley offers a full featured cloud production environment named the Agile Media Processing Platform, or AMPP. And at IBC, we setup a demo showing the use of Waves Cloud MX audio mixer connected to AMPP for state-of-the-art audio processing and mixing – all in the cloud.

The demo layout was straightforward, with audio sources pulled from multiple playback clips routed from AMPP to Waves on NDI, and then returned as main program and mix-minus feeds to AMPP.

In Amsterdam, our demo used Windows PCs as remote clients connected to the cloud processing servers, AWS EC2 instances, that were physically located at an AWS US-West datacenter in Oregon. Yes, 5,000 miles away as the bird flies. Everything we demoed, from the workflow dashboard to a simple multi-viewer and the complete audio processing and mixing environment – was connected via a 10 Mb shared public internet drop at the booth. Using this setup, the latency of the touchscreen controller was around 165 ms; not bad considering the network configuration, and still responsive enough for our touchscreen controller to keep up with typical audio mixing tasks.

Back to my desktop folder on the plane. I wondered if the airplane Wi-Fi would block any of my control ports. In this case I only needed a connection for the remote desktop client (port 8443, AWS Nice DCV) to access the Waves audio mixer, and a secure web browser (port 443, https) to access the AMPP dashboard.

My in-flight experiment started with logging in to the AMPP dashboard. This is accessed through a UI in an HTML5 browser window, and I was able to log in and see my demo dashboard as if I was on the ground. With this connection in place, I was able to start and control the AMPP functions that were part of my broadcast workflow, specifically the playback machines and NDI audio patches.

Image 1: GV AMPP Dashboard used for demo with program feed monitor.

After confirming that my audio connections from AMPP to the Waves Cloud MX audio mixer were in place, I closed the dashboard and proceeded to login to the AWS cloud instance running the audio mixer.

The Waves Cloud MX audio mixer is controlled by connecting a remote client (my laptop) to the cloud server using the PC-over-IP (PCoIP) interface provided by AWS named NICE DCV. In general, any PCoIP client-server implementation can be used, but in this case the NICE DCV software was already loaded on both cloud server and my laptop, so it was easiest to test.

The familiar login window appeared, giving me confidence that the required port access was open, at least over TCP. After login authentication, the Waves Cloud MX mixer appeared, and the channel strip meters displayed changing levels telling me that audio was running before I put in my earbuds.

Image 2: Waves Cloud MX audio mixer control displayed on laptop display below flight tracker on airplane at 36,000 ft, on-route to NYC.

I made a quick check of the network latency using the built-in status monitor on NICE DCV, which reported 800 ms at this point in the flight. Although it was under a second, it was certainly far higher than the latency measured on the ground at IBC. Given this latency, I expected and confirmed that monitoring the streaming audio direct from the mixer had some periodic dropouts. Not unexpected, but not surprising given the airplane Wi-Fi-to-satellite-to-ground-to-cloud and back path that would be required for each packet. 

I ran a few more tests on my remaining US domestic flights on the way home and found that the network latency was substantially lower when using the airplane-to-ground connection – in most cases it was logging just under 300 ms. With this lower latency came a more responsive control interface, whereby adjusting faders or viewing graphic-intensive audio processing plugins was much more natural than my over-ocean experience. 

Furthermore, my in-flight Wi-Fi access was limited to TCP connections, which limited the NICE DCV PCoIP application to the slower WebSocket protocol. If the Wi-Fi provider allowed for UDP connectivity, I could have used the much faster QUIC protocol with NICE DCV, which would have improved the performance and possibly eliminated all audio drops in the stream monitoring. 

However, as in-flight Wi-Fi technology continues to evolve and improve, I anticipate that the protocol limitations will soon be another relic. Recent news suggests that technology such as Elon Musk’s SpaceX Starlink network could be implemented on commercial airlines, promising Wi-Fi speeds as high as 100 Mbps, and opening the technology barrier for in-flight broadcast workflows to become a new normal. 

Until then, broadcast A1s may find that an emergency call to fine-tune the audio processing or program mix while flying to a vacation island is possible, even at 36,000 feet.