Time travel? Or, just clever technology
syncdna.com
syncdna.com
For example, you got a drummer that does their thing.
The bass can react to the drummer.
The guitar and vocals can react to drummer and bass.
Each one could get a finished version, but with so much delay that they can't meaningfully react to each one coming after them or being on the same level.
This is an old trope that needs to die. I used to play synths on a 1st gen iPad back in 2010, it had amazing <5ms latency at a time when you'd struggle to hit that on a PC using external hardware.
Wired headphones have always been around, even now all it takes is a $5 adapter. Bluetooth "aptX Low Latency" has also been around for years, though adoption has been a bit slow. It is quite standard on Android phones. On the Apple side, Airpods have had decent ~100ms latency for a few years (enough for casual gaming), and more recently have a custom wireless, low-latency lossless connection (Apple Vision only atm), and <20ms latency on the new iPhone 17 using Bluetooth 6.
It really is a wireless technology problem. Bluetooth LE audio only came around 2020, and barely adopted. Bluetooth 6 was announced late last year and just starting to show up in devices now.
Android audio stack is notoriously easy to make very very bad. Too many layers of software abstraction. Later upon layer of buffering. It’s all so bad. :(
This needs a big citation. It has always been claimed that AirPods have no discernible latency and every time it is tested it is actually pretty subpar (>150ms).
> Bluetooth "aptX Low Latency" has also been around for years, though adoption has been a bit slow. It is quite standard on Android phones
Almost no Android phones support it. Anything Samsung for example is excluded, even if they use Snapdragon Sound chips.
It is not really a technology problem, since I was doing 50ms latency with plain old HFP profile on BT 1.x back in 2002 with a Nokia and the cheapest headset. Latency has being going up even though nothing really changed in the underlying technology (Classic Bluetooth Audio HFP/A2DP is practically unchanged since Bluetooth 2.x times, while LE Audio introduced in BT 5.x is used by almost no one and their codec selection can be considered sabotage).
The problems are (from an enthusiast & armchair analyst PoV):
- Consumers don't care (YouTube works well, after all) and can't even measure it correctly. Manufacturers don't report latency on specs.
- Everyone has an incentive to make it subpar so that they can promote their proprietary solutions with vendor lock-in. Qualcomm/CSR is _specially_ guilty of this, and they dominate the BT headset industry. But literally everyone is doing it these days (Samsung, Sony, Apple, etc.). And even then, most of the time these techs provide negligible improvements on latency or quality (since, #1, customers can't measure).
- The Bluetooth SIG no longer has any remaining teeth (it never had many to begin with). They just rubber-stamp and things barely interoperate with each other these days (e.g. last Sony headsets "support" LE Audio as per logo but on release could not talk with any of the existing LE Audio stacks).
Here's one from 2022 (so AirPods Pro 2 and iOS 15 or 16), but: https://stephencoyle.net/airpods-pro-2
"As you can see, the second-generation AirPods Pro perform about 40ms better than their predecessors, with an average latency of 126ms vs the original’s 167ms.
"Perhaps a more interesting point to note is that the second-generation AirPods Pro perform only 43ms worse than the built-in speakers (at 83ms). That suggests that up to two-thirds of the time between touching the screen and hearing a noise occurs before Bluetooth data leaves the device. I think there’s still too much latency for audio feedback to feel snappy and responsive over AirPods Pro 2, but maybe at this point there are easier gains to be made by working to reduce the device-side latency."
Things may have gotten much worse recently as I distinctly remember the iPhone around the 4s-6s era having <30ms latency which was a huge advantage over Android.
The Apple Pencil can also go under 10ms latency when drawing, there must be a way of taking advantage of that for music apps?
e.g. rtings puts AirPods Pro 2 at 160ms https://www.computerbase.de/artikel/audio-video-foto/apple-a... (AirPods Pro 3 review is in progress)
and ComputerBase puts AirPods Pro 3 at 160-180ms. https://www.computerbase.de/artikel/audio-video-foto/apple-a...
But there is NO world where you are doing realtime playback/recording even with very loose quantization with an iPad and BT headphones. Maybe some day, but that day is not now.
Latency
- under 30ms = acceptable
- between 30-50ms = irritating but you can work around it
- between 50-100ms = easily detectable when you press a key and almost unusable
- above 100ms = patently absurd
And this is latency figures for laying down melodies. Latency needs to be even tighter when laying down drums.
The only decent wireless headphones I've ever used in a recording setting were AIAIAI TMA-2 Wireless+ [1] which uses a dedicated radio transmitter.
Plug them in directly, no problem.
You can literally even see the video lag when you hit play as it ensures it syncs with the audio.
> A producer sends a backing track to a performer - SyncDNA adds a slight delay to the outbound feed
The "backing track" is probably the beat or something similar.
1) the beat is created live by a human performer who can't meaningfully hear the other performer(s) in time. He / she is stuck with playing blindly.
2) the beat is pre-recorded - sampled or electronically generated on a sequencer. Then what's the use case in the first place? The other performer can download it offline and play on it live.
All this is done to get something that mimics a live performance (but isn't, because the band components can't hear each other in real time) to someone listen-only at the end of the chain. What's the advantage in doing so? What's the use case?
Google and Azure Availability Zones seem to break that limit daily ... ;-)
1. One musician plays simple bars, repetitive stuff, and streams it.
2. Second musician receives the audio from musician 1, records a multi audio track video of himself alone (in one track) and the musician 1 output in another.
3. Stack undefinitely.
You play to what you hear, in real time. All tracks are recorded separately in separate computers and can be edited together quite easily.
Plus, this is already how most jams work in real life.
> "now" isn't a single universal instant, it's a moving target
Rhythm is already a moving target, a delay cycle. Musicians just need to know the beat 1 for each bar (which they should already know, as it is their job).
https://youtu.be/eg_rgm9VDAw?t=1597
The drummer takes a little bit more than a second to react to it (higher than a lot of stream delays by the way, but I can see how the stacking could mess it up).
That is, however, a bunch of experienced jazz musicians improvising at a high level. In most jams, these conversations happen very often on the next bar (1 and 2 and 3 and 4 and you react on the next 1).
You can see a drummer using the end of a bar to cue the flourish used on the organ in this part, for example:
https://youtu.be/jhicDUgXyNg&t=587s
It takes multiple seconds for the organist to recognize the cue, that is actually for the next bar, then he joins in. This sort of stuff is actually doable just with just video chat and OBS.
Please also note that the product's example workflow is actually worse in that "reaction jammyness" regard than what I proposed:
> The performer receives the track early, and waits the rest of the delay period to play it
This is designed for recording. It sounds more like a studio arrangement in which you have to record your part than a jam session.
> The fidelity of the live stream isn't high enough to record
Seems like an incomplete product. OBS can already record multi-tracks and monitor tracks, which you can leverage to produce high quality artifact recordings. I use to sync them manually using a DAW, but with all those auto-timers, it's a surprise it doesn't do it automatically.
If what each person is hearing is 100-400ms delayed from what each person is producing, how can they possibly mutually react or even get their music in time? If B plays in time with what they hear from C, C hears what B did 200-800ms later - that's far too much and will sound terrible.
Jamming would seem to require incredibly low latency audio just for the rhythm to work between two performers.
Also, the stacked delay is part of their product. My solution just does it for free, but it's the same idea.