Research reveals the type of musical instrument – and monitoring environment – impacts the perception of latency.
AES conducted a subjective listening test to identify how intolerable various amounts of latency are for performers in live monitoring scenarios. They discovered the perception of latency depends on the type of musical instrument and monitoring environment (wedges vs in-ear-monitors {IEMs}). This experiment showed the acceptable range of latency is between 42 ms and less than 1.4 ms.
Vocalists can tolerate the least amount of latency (less than 3 ms), followed by drummers (less than 6ms), pianists (less than 10 ms), guitarists (less than 12 ms) and keyboardists (less than 20 ms).
What else do we need to consider?
The audio chain (without a wireless link and for a one-way link) can have a total latency of 10-20 ms.
Why does this happen? This buffering is largely due to:
- Conversion issues: Typically, between analogue and digital domains or frequency and time domains.
- Inconsistent block size across a chain of processing modules: Various digital signal processing algorithms work on blocks of samples, rather than one sample at a time, which requires buffers processed as a single unit. If the block size isn’t consistent across a chain of processing modules, further buffering is needed.
- The challenges of transferring between systems: Wired or wireless transfer of data between systems – such as between different software algorithms, different chips within a single product, different products, or different locations over a network – requires buffers. Transfers typically happen in blocks and can require retransmissions. This can be further compounded when the data size of the radio transfers doesn’t match the typical size of the audio blocks – requiring further buffering.
- Mismatched clocks: Some systems require crossing clock domains to transfer data which can need additional buffers to handle the slightly different rates, and the processing required. Fortunately, some professional systems are designed to run from a common clock to avoid this problem.
Where do latencies occur in a radio frequency (RF) link?
Let’s next look at Bluetooth® LE and UWB (ultra-wideband) technology as possible RF options.
Sometimes the product designer has the luxury of designing their own protocol and using discrete components, but that’s a topic for another day.
For an off-the-shelf Bluetooth® LE SoC-based design, the lowest latency appears to be around 19 ms using a standard protocol and LC3+. Now we have a one-way link (microphone or IEM) that is at best 29 ms. Double that and we’ve got a compounding issue where the 58ms is way beyond the 42 ms cited by the AES paper.
Virscient technology can lower the RF portion to around 3.8 ms.
The good news is we can achieve ultra-low latency audio over low-power wireless links thanks to Virscient’s LiveOnAir – a technology we introduced in 2023 for wireless mics and IEMs.
Using the LiveOnAir Bluetooth® LE link with LC3+ can reduce the RF part from 19 ms to 12 ms. This can be reduced even further with a low latency audio solution. This now delivers an RF figure of around 3.8 ms.
The entire production link is now 13.8 ms and a round trip under 27 ms is achievable.
Moving on to UWB: Super-low latencies make ‘magic’ possible.
When I first heard about UWB, I thought it had almost magical properties – super-low latencies and enough bandwidth to support Linear PCM at 24bit, 96kHz sampled audio (remember that hallowed level I mentioned earlier!).
Big-name device manufacturers like Samsung and Apple are starting to support this technology, raising the profile of UWB as an RF solution. More radio vendors are starting to supply it, and currently UWB is largely used for location and access control. However, due to the frequencies UWB works at, it’s prone to body blocking and de-tuning dropout.
For non-real-time applications or when you can rely on reflections for a signal to arrive, this isn’t a cause for concern.
But for real-time audio, glitching is a cardinal sin. That’s why UWB didn’t used to be an option for real-time audio.