Get rid of echo from your USB mixer

You just brought home a new USB mixer, and you can’t wait to impress your friends with it in an online jam session on FarPlay or in a conference call on Zoom, Skype, or FaceTime. You really do sound great to them, but they complain they hear an echo of themselves, and they track the problem down: it’s you. That’s weird. Sure, echo often happens when someone uses speakers instead of headphones, but you confirmed that you’re hearing the other participants through your headphones; their audio isn’t coming out of your speakers.

Is there a way to get rid of this echo? Why is this happening?

The fix is easy. There’s typically a button on the USB mixer you push to make the mixer stop sending a copy of the audio from the computer back into the computer. The name of the button varies between mixers. At FarPlay’s support session on Saturday October 26th, 2024, I showed attendees where the button was on the Mackie ProFX6v3. Check out the video below.

The steps are similar for common USB mixers:

  • Mackie ProFX6v3: Make sure the USB 3-4 button is OFF (not pushed in). Make sure the TO PHONES button is pushed in. Set the BLEND halfway between INPUTS and USB 1-2 (or to USB 1-2). Don’t set the BLEND to INPUTS. For more information, see the ProFX6v3’s manual.
  • Yamaha AG03/06 and AG03/AG06 Mk2: Set the TO PC switch to INPUT MIX, not LOOPBACK. Gradually raise the USB/computer level knob as needed to hear audio from the computer in your headphones. For more information, see Yamaha’s manuals for their AG03/06 mixers or their AG03/06 Mk2 mixers.
  • Alesis MultiMix 8 USB FX: Make sure the 2 TRK/USB TO MAIN button is not pushed in. Make sure the 2 TRK/USB TO MONITOR button is pushed in. For more information, see the MultiMix 8 USB FX’s manual.

Looking for the button on a different mixer? Search your mixer’s manual for keywords like livestreaming, webcasting, gaming, and loopback. Sending the audio from the computer back into the computer is called loopback. Livestreamers use loopback to let their audiences hear a mix of game audio, for example, with their voice, but loopback creates an echo in online conversations and jam sessions. In short, turn loopback off for sessions on FarPlay, Zoom, Skype, FaceTime, etc.

—David

Twinkle Twinkle Little Star, Jam Together From Afar

We’re hard at work on the next version of FarPlay. If you haven’t already, upgrade free to the latest version.

A little housekeeping: Shortly after Apple released macOS Sequoia 15.0, reports of issues with different firewall and network software began popping up. If you’re running into networking issues on Sequoia, go to your Mac’s Local Network settings and flick the switch to give FarPlay permission, as shown on our forum.

What’s packet re-requesting, and what does it have to do with recording?

Musician, composer, and FarPlay co-founder Dan Tepfer talks about packet re-requesting, a powerful new feature in FarPlay 1.3 that helps you make pristine recordings over a wider range of connections. Read the transcript on our blog.

Variations on Twinkle Twinkle: No. 1

Speaking of pristine recordings, Johan Eriksson Rapp and Anders Teglund return to our newsletter with the first of a series of variations on “Twinkle Twinkle Little Star”. They recorded the audio and video for this studio-quality single live in FarPlay, not separately, giving them the opportunity to relate organically in real-time. Listen to the stellar single on SpotifyApple Music, and Amazon Music, or watch the video below.

Distansorkestern (“Distance Orchestra”) band members Johan and Anders are Swedish composers who use FarPlay to rehearse and record live from Falun and Kungsbacka, Sweden, 250 miles (400 km) apart.

Happy birthday, FarPlay monthly support sessions!

Thank you to our community for a wonderful year of FarPlay monthly support sessions. It’s been so much fun to help and meet you.

Songwriter/producer Maat Hotep came to our session on September 14th, 2024 to find out what it takes to get started with FarPlay. Watch highlights below and visit our QuickStart guide.

Sign up for our support session on Saturday October 26th 2:00pm-3:30pm New York time (8:00pm-9:30pm Central European time). Monthly tech-support sessions are available free to paid subscribers. 

Get in touch

Do you love FarPlay and have experience with marketing? Would you be interested in helping us with our mission of making low-latency audio available to everyone by helping us spread the word? If so, email us at contact@farplay.io.

We’ve been loving featuring our amazing users. If you’d like to be included — whether you use FarPlay for lessons, rehearsals, jam sessions, or conversations — we’d love to talk to you. You can let us know by emailing us at contact@farplay.io.

Need help right away? Check out our FAQ & Troubleshooting Guide.

If you’d like to ask tech-support questions, our forum is the fastest way to reach us. If you need to reach us privately, email us at support@farplay.io — we’re happy to help!

We hope you’ve been enjoying FarPlay 1.3!

—David Liao & the FarPlay team

Pristine recordings over a wider range of connections thanks to packet re-requesting in FarPlay 1.3

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.

A bug in macOS Sequoia 15.0’s firewall could have been disastrous for FarPlay. But we found a way to keep the music going.

When we got the first report that FarPlay app failed to connect after upgrading to Sequoia 15.0, we checked the logs and found that most users who upgraded hadn’t experienced issues, so we thought it might be a one-off case. But after receiving several more complaints it became clear: we had a problem.

FarPlay is an app that allows musicians to make music online interactively. This requires much lower latency than common audio/video conferencing apps provide. To make online jamming feel like you’re in the same room, end-to-end latency needs to be below 20-30ms. That’s why FarPlay relies exclusively on peer-to-peer (P2P) technology. It allows us to use the shortest and the fastest possible path to deliver audio data from one side to another. But P2P connectivity depends strongly on firewall behavior. Firewalls that are too restrictive or incorrectly configured can easily make P2P connections impossible.

Shortly after Apple released macOS Sequoia 15.0, reports of issues with different firewall and network software began popping up. Customers of large security software companies like CrowdStrike, ESET, and SentinelOne reported issues. Some VPNs stopped working too. For some FarPlay users, it looked as though their firewalls just started blocking audio traffic entirely even when their firewalls were turned off completely in system settings. At the same time, others didn’t experience any issues. I was not able to reproduce the problem on my test Mac.

We are a very small company, just a few people. If IT security giants couldn’t solve the issue, what could we do? About 60% of our users are on Mac, and even if only 10% were affected, it could have been disastrous for us. When P2P connectivity is broken, FarPlay simply can’t work. A music teacher can’t provide a scheduled lesson. Musicians can’t conduct their final rehearsal before a concert.

We began researching the changes in the new version of macOS and discovered that the new “Local Network” section in the “Privacy & Security” settings affects FarPlay connectivity. This setting has existed in iOS for a while and has now been added to macOS. Normally, it would only be required for connecting FarPlay clients within the same local network. However, we found that enabling this setting for the FarPlay app also resolved the connectivity issues for users affected by the Sequoia firewall problem.

So, if you have a networking issue with Sequoia, check out the Local Network section of Privacy & Security settings. I can’t say if this helps with other Sequoia issues, but it was a lifesaver for us. Shortly after we published this workaround on our support forum, other users confirmed that it worked for them as well.

Just recently, Apple released Sequoia bugfix version 15.0.1. As usual, its description is vague, it says it “improves compatibility with third-party security software”. We don’t have enough data yet to say if our problem was fixed with this update. Our users already had a solution at that point.

—Anton