odd occurrence jacktrip-to-Zoom link

[Christian Fritze]

Greetings all:

We're beginning to use jacktrip for choral rehearsals. We have a growing set of jacktrip pioneers using Virtual Studio devices (currently about 30) and about 100 singers who haven't started using the jacktrip yet. Everybody is in a Zoom rehearsal - the zoom-only folk singing along with muted mics. We are just beginning to pipe the jacktrip sound into the Zoom rehearsal for the benefit of the zoom-only singers using the technique described by Jan Stoltenberg in his excellent youtube tutorials. Our jacktrip>Zoom tech is running jacktrip on macOS using BlackHole as a bridge.

This has worked splendidly in five or six practice sessions we've had with a small group, but as luck would have it, the first time we attempted to premiere it in a session with our full chorus, the feed received by Zoom was horribly garbled - strange noises, delays, echos, crackles - anything but the clear sound we usually experienced. After an hour of going back to a regular Zoom rehearsal, we tried again and got wonderful sound.

Have any of you experienced anything like this? We couldn't reproduce the problem on a smaller session the next day. We are pretty sure our jacktrippers had their zoom audio and speakers muted, and their sound within the jacktrip "room" was fine - just the Zoom pipe was garbage. Is there any reason to think having 130 folk on Zoom stresses the process? Or sometimes the Connections between jacktrip/blackhole/Zoom don't "take" with fidelity? We're trying to get a sense of whether this was an act of god or a process oops that we could be on the lookout for. 

Thanks for reading, and any thoughts!

Christian 

[Dave Adams]

Can you expand a bit on just what your "jacktrip->Zoom tech" is doing AND is set up?

I am dancing on a knife edge with Comcast upload bandwidth.  If I tried to send out a Zoom audio channel, AND a Zoom video channel, AND a jacktrip channel, I would get poor resuts on all three.

If, on the other hand, your "tech" is NOT sending his audio to JackTrip for the mix, most macOS machines would have the horsepower to pull down the JackTrip audio and Blackhole it to Zoom.

Does your "tech" have full control of the Zoom session?  All it takes is ONE person off mute typing near the computer microphone to garble everything...

There are many possibilities, so some more info on my first line above would help the folks here who really know what they are doing.

BTW: just had a trombone choir rehearsal.  Because of installation concerns with Windows or Linux drivers we decided to hardwire from a Virtual Studio Device to a headphone amp to an older laptop with stereo mic input.  Worked great during testing.  Worked not at all when we really wanted it.  So we're back to testing again.  Since it worked it's that little matter of taking better notes this time around :) 

[Dan Lyke]

On Wed, Mar 31, 2021 at 10:48 AM Dave Adams wrote:

> I am dancing on a knife edge with Comcast upload bandwidth.  If I tried to send

> out a Zoom audio channel, AND a Zoom video channel, AND a jacktrip channel,

> I would get poor resuts on all three.

Sidetrack, but maybe useful for someone: obs.ninja is a web-based video conferencing platform that lets you specify a max (kinda) upload bandwidth to use, via the "&bitrate=500" (or whatever, that number works fairly well for me) flag on the URL.

This works fantastically for my voice teacher who's stuck with Comcast, where every attempt with using Zoom or Facetime or Google Hangouts was choking out her upstream and destroying our audio (and, for whatever reason, the effect of bandwidth choking was worse on JackTrip than on Jamulus; we settled on JackTrip for other reasons).

[Christian Fritze]

>>Worked great during testing.  Worked not at all when we really wanted it.

Ha! So it’s a known syndrome.  ;-)

Our tech (me) is running the Zoom app and the qjackctl/jacktrip client on OSX /Big Sur. I’ve got oodles of network headroom (fiber). I’m in fact using Blackhole as the bridge much as described in Jan Stoltenberg’s youtube tutorials (video 4.2 in his series). We’ll keep tinkering, but also go back to working with the method you described above, taking output from a spare VS device into a laptop. Maybe redundancy is the best protection...

[Dave Adams]

Does your Zoom app have session admin priviledges?

With the PC and  fiber capacity you have, I can't see how you'd have problems on those two fronts.

Before I'd try hard-wire patching I'd double check the Zoom muting.

Then I'd check the sound on each participant in full voice.  All it takes is ONE member with sub-par upload bandwidth and the whole mix can get quite ugly.

I hate to suggest the next item, because it's kinda like "did you plug it in?"  But I HAVE spent debug time looking in arcane places, THEN asked the obvious question.  So, in this case, have you double checked the routing of the "patch panel?"  I learned working with Ardour to record some tests that it was TOO easy to overlook a troublesome link in the Linux Jack "Connect" screen.  I eventually removed ANY connection that was not ESSENTIAL to capturing, then playing back, with Ardour.  Capture and Playback required different connections.  Any time I forgot that I got nasty results in the jacktrip mix.

THEN I might check out the hard-wire.  THAT has challenges too.  In particular, just getting around line-level/mic-level/headphone-level volume AND impedence mismatches  can be quite a headache.  I now have a little box of assorted resistors for soldering different pads to 1/8" TRS jacks for jack_delay and/or amp output/audio input adapters.

I think the non-mac equivalents of Blackhole will become more available without installation headaches.  I intend to go that route at some point.

[Dave Adams]

Dan,

Nice reference.  I'll look into it.

Thanks!

[Dave Adams]

obs.ninja looks like a partial solution to part of the "jacktrip->zoom" challenge.

I had looked at obs to try to reduce the video upload bandwidth of the Zoom.  Getting the camera setup and linked to Zoom was just plain punitive for me.  I did NOT want to have to try to coach Windows, MacOS, and Linux users through it!

If I get it right, obs.ninja bypasses Zoom entirely and, at the same time, gives simple full control to obs for setting the bandwidth hunger of the video. 

Ends up being a peer-to-peer-to-peer-to-peer mesh though.  For ONE pair of videos it would be great.  For a choir it would be, again, punitive to set up.  Plus, if I get the setup right, I think it ends up sending the video from each peer out  to all the other peers.  If so, then the upload bandwidth savings from reduced video content gets eaten up by multiple connections. I'd have to go over the obs.ninja architecture to see just how and where the peer matching is done.  Something to look forward to :)

I'm keeping your note in my "spare-parts" kit, just in case I DO have some one-on-one cases.  Coaching ONE person through setup is a lot better than coaching a whole choir :)  ... and there MAY be ways to get a whole choir without Zoom and without a lot of coaching.  THAT would be cool!

On Wednesday, March 31, 2021 at 2:29:50 PM UTC-4 danl...@gmail.com wrote: