iPad-based audio pre-processor for Zoom lessons and sessions

[Michael Eskin]

Since I’ve gotten some nice comments on my sound quality from other players while using my new iPad-based dedicated audio setup for Zoom sessions, I’ve put together a detailed article on the setup, including the hardware and software I use as well as the settings for each of the plugins:

http://appcordions.com/zoom/#zoom_ipad_appliance

[David Barnert]

Interesting. Do you find that it has any effect on (increases or decreases) the latency that makes Zoom so awkward for trying to play together across the internet?

[Michael Eskin]

It doesn't change the latency or have anything to do with fixing that issue. Zoom is what it is.

Nothing we can do fixes the latency inherent in Zoom, but we can, through Zoom audio settings and optimizing our own audio equipment do the best we can to provide excellent quality audio for others to listen to.

 

This setup is about providing the best possible audio into Zoom for the "one-at-a-time" style sessions I and many other have been hosting.

You could use the same setup with any internet streaming system like JamKazaam, this is just a stand-alone audio processing system.

Edited July 19, 2020 by eskin

[alex_holden]

Do you have to run Zoom on a separate computer with an audio cable from the iPad, or could you just use the Zoom app on the iPad? I'm guessing that wouldn't let you adjust the levels during the session but could it at least run in the background and feed filtered audio into Zoom?

[Michael Eskin]

No, this system unfortunately can’t feed Zoom running on the same iPad. The Shure MV-88+ probably could be used alone with Zoom without the AudioBus-based audio processing chain, but there is no bridge possible between Zoom on iOS and other audio apps.  
 

This is really meant to provide high quality processed audio to a Mac or Windows computer. In my case it replaces a rack full of dedicated audio processing hardware that I previously used to achieve the same results and has far more control and flexibility.

Edited July 19, 2020 by eskin

[RAc]

4 hours ago, eskin said:

It doesn't change the latency or have anything to do with fixing that issue. Zoom is what it is.

Nothing we can do fixes the latency inherent in Zoom, but...

 

Some splitting hairs in two:

 

The latency is not inherent in Zoom; the front end software is only one contributing factor. The major issue (we discussed this before) is packet turnaround in the internet infrastructure.

 

Thanks, Eskin, for the description!

[David Barnert]

16 hours ago, eskin said:

This is really meant to provide high quality processed audio to a PC or Windows computer.

 

Any reason it shouldn’t work with a Mac?

 

Edited to add: This post is no longer relevant.

Edited July 20, 2020 by David Barnert

[Michael Eskin]

Sorry, typo, it should work just fine feeding audio to a Mac or Windows computer line-in audio input...  fixed it in the original post.

Edited July 19, 2020 by eskin

[Michael Eskin]

9 hours ago, RAc said:

 

Some splitting hairs in two:

 

The latency is not inherent in Zoom; the front end software is only one contributing factor. The major issue (we discussed this before) is packet turnaround in the internet infrastructure.

 

Thanks, Eskin, for the description!

I meant “inherent in Zoom” to include both the client and their server-based service infrastructure, not just the client software.  More in comparison to a pure peer-to-peer system like JamKazam where low latency group play is quite possible up to about 1000 miles distance with ideal hardware configuration and network connections.

 

Edited July 19, 2020 by eskin

[Michael Eskin]

Quick demo video:

 

 

Of course, all aspects of the compression, EQ, and reverb can be adjusted to your own preference. 

 

Edited July 19, 2020 by eskin

[Michael Eskin]

I’m playing around with the EQ and Reverb settings to dial the vocal low end boom back just a bit from what's on the demo video. That’s the beauty of the setup, very easy to make tiny tweaks and save them as presets. Really, it’s the compressor that makes a big difference, particularly when playing instruments.

[David Barnert]

If I’m understanding this, the signal passing between the iPad and the PC is analog (headphone jack to audio in)? That is, the mic creates an analog waveform which is digitized and processed in the iPad, exported as analog to the PC where it is digitized again for export to the internet (via Zoom, or whatever).

 

Is that correct?

[RAc]

21 hours ago, eskin said:

I meant “inherent in Zoom” to include both the client and their server-based service infrastructure, not just the client software.  More in comparison to a pure peer-to-peer system like JamKazam where low latency group play is quite possible up to about 1000 miles distance with ideal hardware configuration and network connections.

 

 

I believe I understand what you are getting at when comparing pure peer-to-peer software packages like JamKazam to One-to-many video conferencing software systems like Zoom or Microsoft Teams. In the latter, there is an additional complication relating to the fact the multiple "audio feeds" from several clients must be processed quasi-simultaneously; thus, optimizing and reducing data stream sizes in this case buys possible additional performance.

 

Yet, in either case, the factor that blows the show is the internet itself (as we know by now, thanks among other things to Jody's sharing of experiences). If all your neighbors hooked up to the same provider and same switch on the provider's side are watching hi-res cat videos while you try to Jam via any conferencing software, you're out of luck. In that case, additional cutting down on traffic may help you in pushing a Zoom conf quality a wee little bit towards the maximum possible JamKazam quality under the same network throughput restrictions, but I'd assume you'll never get beyond it, right?

    

[Michael Eskin]

New demo video with improved voice EQ.

I found the voice EQ in my original demo video a bit "boomy", this is better:
 

 

The benefit for the whistle (would be true for concertina as well) is primarily provided by the compressor, which limits the maximize volume and provides a more comfortable listening experience to others on the conference.

Edited July 20, 2020 by eskin

[Michael Eskin]

6 hours ago, RAc said:

 

I believe I understand what you are getting at when comparing pure peer-to-peer software packages like JamKazam to One-to-many video conferencing software systems like Zoom or Microsoft Teams. In the latter, there is an additional complication relating to the fact the multiple "audio feeds" from several clients must be processed quasi-simultaneously; thus, optimizing and reducing data stream sizes in this case buys possible additional performance.

 

Yet, in either case, the factor that blows the show is the internet itself (as we know by now, thanks among other things to Jody's sharing of experiences). If all your neighbors hooked up to the same provider and same switch on the provider's side are watching hi-res cat videos while you try to Jam via any conferencing software, you're out of luck. In that case, additional cutting down on traffic may help you in pushing a Zoom conf quality a wee little bit towards the maximum possible JamKazam quality under the same network throughput restrictions, but I'd assume you'll never get beyond it, right?

    

Bandwidth isn't as much a problem for as is number of hops between users and if the system is peer-to-server (Zoom) or peer-to-peer (JamKazam).  I believe that Zoom mostly runs peer-to-server, so there is additional latency added with each user's stream going to a Zoom server, then to each client. In JamKazam, it's all peer to peer, so it's entirely dependent on the ping latency between the nodes, plus the local audio system and internet connection latency and jitter.  JamKazam doesn't require much bandwidth when using just audio, so shared connections at a local cable switch may not impact the overall latency, but if there are many hops between peers, it adds up.   I have wondered if Zoom runs peer-to-peer if there are just two users on a meeting, but not sure.

[RAc]

12 hours ago, eskin said:

Bandwidth isn't as much a problem for as is number of hops between users and if the system is peer-to-server (Zoom) or peer-to-peer (JamKazam).  I believe that Zoom mostly runs peer-to-server, so there is additional latency added with each user's stream going to a Zoom server, then to each client. In JamKazam, it's all peer to peer, so it's entirely dependent on the ping latency between the nodes, plus the local audio system and internet connection latency and jitter.  JamKazam doesn't require much bandwidth when using just audio, so shared connections at a local cable switch may not impact the overall latency, but if there are many hops between peers, it adds up.   I have wondered if Zoom runs peer-to-peer if there are just two users on a meeting, but not sure.

 

Ok, thanks for clarifying. You're arguing in terms of message broker latency. Should be easy to figure out how Zoom does it in either case, I'll give it a shot later this week by wiresharking the network traffic when doing my next Zoom conf. I suspect it's message broker usage (MQTT?) regardless of the number of nodes.

 

I also suspect that even pure peer-to-peer systems like JamKazam utilize message brokers - even though they don't need them technically -  for several reasons ("just" ones such as being able to queue connection requests to peers even when Offline such as in SIP as well as "greedy" ones such as being able to control the server end for possible sources of income).

 

I did a quick search but the only remotely related discussion I could find was here: https://medium.com/@gjovanov/building-your-own-slack-54874bf5fd7a

 

 

[David Barnert]

12 hours ago, eskin said:

I have wondered if Zoom runs peer-to-peer if there are just two users on a meeting, but not sure.

 

I doubt it. My brother (140 miles away, in Cambridge, MA) and I did a 2-person Zoom a few months ago and tried this experiment: We agreed each of us, in turn, would say “One, two, three, clap” and we would clap at what seemed like the same time. The result, as expected, was that in each case the one who did the counting heard the other clap about a half second late.

[Michael Eskin]

Zoom's own article seems to imply they are never peer-to-peer:

https://blog.zoom.us/cloud-based-and-peer-peer-meetings/