I think the intent is to choose one of vMix's available outputs, and then change what is sent to Zoom by changing what you send to that output.

I certainly agree that it would be much better if one was able to change the return video AND audio feed for Zoom calls after the connection is made.

For now we use shortcuts and trigger to control an audio bus dedicated for the audio return to Zoom.

On a side note we will probably host the Zoom meeting on a separate tablet/PC for safety reasons. I learned the hard way a while ago that it is dangerous to be dependant on one single PC for both the video production and the Zoom management. Hosting Zoom meeting separately offers the additional benefit of being able to talk/listen to the meeting via the host device.

My interpretation is that the host is on a separate laptop. So, on the laptop, start the meeting, then join in vMix as a guest (rather than host). That way, if the PC dies, you don't lose vmix AND the meeting, as the meeting is hosted by the laptop.

I presume (will test tomorrow when back at my machine) this means that you don't need to kill the entire meeting when changing video/audio source in vMix, as the host laptop continues hosting and the guests don't get disconnected. Then all you need to do is reconnect vMix as a guest again and reassign the other guests to inputs.

Using (v 27.0.0.58)-to bring in guests from Zoom calls

I created a few Zoom inputs and joined a Zoom call hosted on another computer. The video connects easily for both Zoom sources, but the audio fails to connect. The participants hear each other but vMix doesn't get their sound. I have the audio activated in the inputs.

I tried a different computer with a vMix instance, and it gives me the same result. I tried restarting vMix and rebooting the computers with no luck.

Any suggestions? Thanks. What am I missin?

There is, depending on how you've set up the routing of devices to various audio busses.

I pick a bus to be used for outputs to various targets, then I use Companion to assign various sources to those busses.

So I'll make Output 4 an NDI output and assign it Bus G in vMIx.

Then, by adding or removing my microphone from Bus G, I can do talkback to Zoom guests. I can also make a button that, while held, puts my mic on that bus, takes that bus off master so it is not broadcast, and solos that bus so I'm hearing only that.

I leave the bus the remote is listening to the same, and take the other devices on or off that bus.

I also use G as my green room, and A for playback and B for mics, so I take people on or off live by either adding or removing their output from the appropriate bus, or moving the designated bus on or off master, but my remotes, whether they are vMix Call or Zoom, are always listening to G.

I'm guessing the issue is what while it can be done in the app, it is not exposed to the API.

Ultimately this is just a personal preference, I guess-- I already prefer to work where I'm dedicated a bus for this use and I take devices on and off it-- I don't necessarily need two button presses, I just need buttons that move multiple devices on and off the relevant bus to toggle talkback, and since I'm already used to working that way with vMixCall, changing to Zoom does not require me to change, so I'm just lucky in that respect. If your workflow depended on changing which source goes to Vmix Call, then that breaks for Zoom because we currently can't do it.

I'm speculating that it's not supported in the API because I think if it was they'd have already implemented it, since they do have that functionality for vMix Call.

That's what I'm getting at about Zoom, though. It makes sense for vMix to implement this feature for vMix Call because each call is individual. But no matter how many Zoom inputs you configure, you're only in one meeting; as far as I know, there's no way to talk to just one participant in the meeting, you're always just talking to the meeting, unless you're using the backstage functionality of a webinar, and even then, I think you're speaking to everyone who is backstage.



It's not! But that won't be possible with Zoom even if vMix implements the feature you describe, because AFAIK Zoom doesn't have this functionality at all.

That is the backstage functionality in Webinar-- that's how Zoom implements this. But vMix isn't going to be able to make this work the way it can with vMix Calls, because whether you're speaking or appearing onstage or backstage in Zoom is based on where your account is. If you're one-manning a show and appearing in a Zoom webinar via Vmix, you can't be "onstage" providing program video and audio to webinar participants, and simultaneously be "backstage" doing off-air comms with future presenters. I think the presumption that underpins Zoom's design choice in this area is that events are first and foremost Zoom events, and everything else is secondary. A lot of our events are recorded, streamed, but also hybrid-- so the audience just isn't the target of vMix's program audio and video feed, but may be watching live on YouTube *or* spectating via Zoom.

So if you're only worried about vMix program audio/video as the audience, you're free to assign whatever outputs you want for each individual vMix Call participant, and route audio to and from a TD or between remotes as you describe, and as long as none of it goes to program, you're fine. But Zoom muxes all the audio in the cloud, so if you're in a meeting, there's no way to send audio to particular participant but not the others, and no way short of using the webinar backstage feature of sending audio that isn't going to the Zoom event's equivalent of "program".

I guess this is just a long way of saying that vMix Call was built to be a solution for both remotes coming on to program and to provide comms, whereas Zoom's design presumes it is a first class program output. If Zoom had a way, in the webinar backstage, of routing audio from one client to one or more clients without going onstage OR to the general backstage feed, then it'd be woth vMix implementing input device level changing for a Zoom input, but without that, it's not that missing feature that's stopping it from reaching feature parity with vMixCall, it's that Zoom assumes you have one big room, or at best, one big stage and one big backstage, whereas vMix Calls are isolated by design, and if you want one big backstage, you have to build it that way yourself.

I only hope that vMix's choice to implement Zoom the way they have doesn't mean they'll give up on vMix Call.