Musician, composer, and FarPlay co-founder Dan Tepfer talks about packet re-requesting, a powerful new feature in FarPlay 1.3.
Read the transcript
Hi, I’m Dan Tepfer. I’m co-founder of FarPlay with Anton Runov. I’m also a musician and composer. I actually use FarPlay all the time in my music, and I want to talk to you about a feature that we’re introducing in FarPlay 1.3 that I’m super excited about. It’s an under-the-hood-type feature. And so I want to take the time to explain it because it’s so important.
So this feature is called “Packet Re-Requesting.”
FarPlay is amazing at minimizing the latency, the amount of time between when you make a sound and your partner or your friend hears it through the internet. And this presents a lot of challenges. The way audio data is sent through the internet is in little chunks, and these chunks are called “packets.” So you’re over here and you’re sending this constant stream of packets over to your friend. And since we’re trying to minimize latency as much as possible, you might think that as soon as you receive a packet over here, we would want to play it right away into the headphones of your friend. But if you did that, you’d run into a really big problem, which is that the internet is a complicated place. Conditions change all the time. There’s congestion, and the amount of time that it takes for a packet to get from you to your friend can vary, and that’s called “jitter.” So, to compensate for that on the receiving end, we introduce what’s called a “buffer,” and that’s just a little bit of a waiting period before you play packets that have arrived. And the purpose of that is that, thanks to that little waiting period, once you finish playing that first packet, it’s very likely that the second packet will have already arrived. And so you can play an unbroken stream of audio.
Now, FarPlay is super powerful in that we give you complete control over the length of that buffer. That’s what changing the latency slider does. And so you can choose to make that buffer super, super short and to play packets almost as they arrive. And as a tradeoff, you’re probably going to hear some static in your headphones. They’re going to be some packets that won’t have arrived yet, and that’s just something you control. You can control it however you want.
And that’s all well and good for playing music, but one of the great things that FarPlay does is it makes recordings. You know, we can make studio-quality recordings with separate stems. And so in that recording, you can’t tolerate static, right? You need really clean audio. And so what we do is, instead of using that super-short buffer that you’re using for your own monitoring, we have a separate really long buffer that we use for the recording. And so the hope is that that buffer is so long that by the time the recording is made, all the packets will have arrived, even the very delayed ones, because of the jitter.
But, actually, you run into a problem with that approach. And that problem is that some packets on the internet, for complicated reasons, simply never arrive. It’s like the mail. You send a letter; there’s always a chance that it will never arrive. And so they just are gone. You’ll never get them. And so what’s the solution to that?
Well, in FarPlay, 1.3, we implemented the system that re-requests packets. So on the receiving end, if a packet hasn’t arrived by a certain time, we send a message to the sending end saying, “Hey, we never got that packet. Could you send it again?” And so it gets sent again, and then it gets slotted into the recording at exactly the right spot. And what we have now with FarPlay 1.3 is that even under challenging network conditions, you can guarantee, within limits, but, basically, for most connections, you can absolutely guarantee a pristine studio-quality recording. And I’m super excited that we’ve finally implemented this. This is something we’ve been wanting to implement for a long time, and hope you find it as useful as I do.