Noises when piping Jacktrip audio to Zoom

[Christian Fritze]

Is anybody else running "hybrid" rehearsals? We have ~35 singers in jacktrip with our conductors on a managed server, and about 100 additional members of our chorus in a Zoom meeting who hear the jacktrippers in Zoom. One of our techs pipes the sound from jacktrip to Zoom, and there is a strong crackle/static artifact that we're trying to eliminate. We use two different setups:

1. we take the headphone out from a jacktrip Virtual Studio device, pass it through a Scarlett 2i2 and into a windows computer audio in port, and set Zoom to treat that audio-in as its mic input

2. we have a jacktrip client running on Mac OS and use qjackctl to connect the receive ports to a Blackhole virtual audio channel that is then in turn set as the mic input for Zoom.

The crackle is present similarly in either scenario, we don't hear it in the jacktrip space, and we can change its character with the various Zoom noise suppression settings - and Original Sound in Zoom is not the best setting for us. This suggests to us that it's something about the Zoom feed that is introducing the artifact, perhaps some lack of clean handoff between what is coming in from JT and what Zoom sends into the meeting? Perhaps one of you who knows more about these systems who might recognize what we could do better? An example of the sound is linked here (pardon the  2 or 3 secs of dead air at the start). Thanks for any assistance.

- Christian

[Synthia Cynthia Payne]

yes lots of similar activity as yours going on - thanks for posting good
details, and including a sample of the sound you are hearing.

Just off the top of my head: that it's more flutter than crackle, and
that to me suggests a sample rate mismatch. Check that all devices that
have a sample rate and frames per period match, including the Scarlett,
JACK and any other devices in the chain - especially the managed server.

Using the Scarlett on Mac does not require a driver, but set the sample
rate for it in Audio-Midi setup. On Windows you will need the ASIO
driver they offer for the Scarlet on the Focusrite website. The ASIO4ALL
driver does not work well, if at all.

another thing I thought of is if you are using a 3rd Generation Scarlett
in a USB 2.0 port, that could cause problems.

all this said, I'm thinking you should be able to set the zoom input as
the scarlett, but I see you have a mac running a Jacktrip client too and
I am not exactly sure about that part.

hope this helps in some way!

synthia

> <https://drive.google.com/file/d/1UuTnyAa_abwd6dRvY5_fmNH3LukjKw2D/view?usp=sharing>

> (pardon the  2 or 3 secs of dead air at the start). Thanks for any
> assistance.
>
> - Christian
>

> --
> You received this message because you are subscribed to the Google
> Groups "jacktrip-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jacktrip-user...@googlegroups.com
> <mailto:jacktrip-user...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jacktrip-users/c79bf047-e13a-458d-822b-c28f4b621b88n%40googlegroups.com
> <https://groups.google.com/d/msgid/jacktrip-users/c79bf047-e13a-458d-822b-c28f4b621b88n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Christian Fritze]

Thanks for the input. I didn’t explain myself clearly.  My 1. and 2. are alternate setups, run by different people on different evenings, one on scarlet/windows the other mac. Because we’re hearing the same flutter regardless of who is doing the piping or with which setup, we figure there’s some other common denominator, like either a zoom “feature” or some other setting that we’ve independently gotten wrong with both of these two very different ways of piping JT->zoom sound 

[Marcin Pączkowski]

and Original Sound in Zoom is not the best setting for us.

Why so? I can't think of any reason to not want the original sound to be active on zoom for transmitting music. Zoom's sound processing typically has an adverse effect on music and thus Original Sound is recommended/required.

Is there a way for you to share a recording of that crackle/static you are describing? It could be many things, but it might be helpful to hear it in order to find the reason for it.

Marcin

[Christian Fritze]

Link to a sound sample in my original post. We tested all the zoom setting meticulously. Original sound off with nose suppression auto reduced the flutter/crackle dramatically. But it’s still there. This sample was recorded with these settings, but I think the original cause of the flutter preceded this. The noise suppression helps, but it’d be even better to identify the original cause. 

[Marcin Pączkowski]

Ah, sorry I missed the sample.

To me it does sound like a buffer under/overrun issue. If you are positive that it doesn't happen coming from the VS device, then it must be something with both Zoom setups.

In the case of Windows, is Zoom using Scarlett for both audio input and output? Does the crackle occur when monitoring directly through Scarlett (without Zoom running)?

In the case of macOS, is BlackHole set up as an aggregate device with the device that's also used as input/output? If not, then I'd try that, and I'd make sure that "drift correction" is checked for BlackHole. I'd use that aggregate device in both zoom and QJackCtl (unless QJackCtl uses BlackHole as both input and output).

Marcin

--

You received this message because you are subscribed to the Google Groups "jacktrip-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jacktrip-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacktrip-users/2f6d1f67-e813-4599-8326-7db126483cb5n%40googlegroups.com.

[Synthia Cynthia Payne]

good stuff, Marcin, thank you. Question: my understanding is that 'drift
correction' is only for devices that have a clock source, or is it the
other way around and that it's for virtual connections like Blackhole
that *do not* have a clock? that would make more sense, but do we have a
number of reports of checking drift correction causing unexpected probs.

christian: please let us know how it goes.

synthia

> <mailto:jacktrip-user...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jacktrip-users/2f6d1f67-e813-4599-8326-7db126483cb5n%40googlegroups.com

> <https://groups.google.com/d/msgid/jacktrip-users/2f6d1f67-e813-4599-8326-7db126483cb5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "jacktrip-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jacktrip-user...@googlegroups.com

> <mailto:jacktrip-user...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jacktrip-users/CAEBNZeAjkCEAp1T99y2u%3DZ42PkjZZCW0uJ2ApceOxPMjgPK0Rg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jacktrip-users/CAEBNZeAjkCEAp1T99y2u%3DZ42PkjZZCW0uJ2ApceOxPMjgPK0Rg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Synthia Cynthia Payne]

and I've been listening to it again, and yes, those are simple dropouts
and likely the buffer size like Marcin said. So increasing the number of
buffers (or frames as it's called in JACK) will likely smooth things
out, buuuut the tradeoff is that latency increases. Maybe there's a
sweet spot. If necessary, send mono only, and reduce demand on local
internet usage or increase service level (higher cost). Lots of small
tweaks can improve service and quality, and reduce latency.

On 5/16/2021 10:54 PM, Marcin Pączkowski wrote:

> <mailto:jacktrip-user...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jacktrip-users/2f6d1f67-e813-4599-8326-7db126483cb5n%40googlegroups.com

> <https://groups.google.com/d/msgid/jacktrip-users/2f6d1f67-e813-4599-8326-7db126483cb5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "jacktrip-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jacktrip-user...@googlegroups.com

> <mailto:jacktrip-user...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jacktrip-users/CAEBNZeAjkCEAp1T99y2u%3DZ42PkjZZCW0uJ2ApceOxPMjgPK0Rg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jacktrip-users/CAEBNZeAjkCEAp1T99y2u%3DZ42PkjZZCW0uJ2ApceOxPMjgPK0Rg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Marcin Pączkowski]

good stuff, Marcin, thank you. Question: my understanding is that 'drift
correction' is only for devices that have a clock source, or is it the
other way around and that it's for virtual connections like Blackhole
that *do not* have a clock? that would make more sense, but do we have a
number of reports of checking drift correction causing unexpected probs.

Every device, virtual or not, "ticks" at a specified sample rate, i.e. it has a clock source. The only difference with the virtual device is that its clock is based on CPU clock, not on audio hardware's clock (unless the virtual device explicitly synchronizes with audio device's clock which BlackHole doesn't do - yet).

When using multiple devices as an aggregate device, their clocks either need to be synchronized (in some way, external devices can be synchronized with a digital connection like ADAT or with WordClock), or one of the devices needs to be used as the primary clock and other device(s) need to be resampled according to that clock (this is the "drift correction" feature). If that's not done, problems will ensue (buffer under/overrun on input or output, and/or drift in recorded tracks). 

When using the built-in soundcard for input and output, even though they present themselves as two different devices, their clocks do not need to be synchronized (if they're set to the same samplerate), since they do take the clock from the same hardware source AFAIU. But when using e.g. built-in soundcard as input and USB soundcard as output, or virtual soundcard as input and physical soundcard as output, they have no way of being in sync and one of them should be resampled ("drift correction").

(In case that's not clear already - the "clock source" in the aggregate device's setup should be set to the device that does not have the drift correction checked)

One thing that's still a mystery to me is that the drift correction (i.e. resampling) seems to be automatically applied in most cases when using different devices as input/output e.g. in zoom - at least on macOS I can typically use a different device for input and output and that works fine for me. However, I always feel suspicious about it and when dropouts like Christian's occur, I'd try to manually enforce resampling when mixing the input and output devices.

and I've been listening to it again, and yes, those are simple dropouts
and likely the buffer size like Marcin said. So increasing the number of
buffers (or frames as it's called in JACK) will likely smooth things
out, buuuut the tradeoff is that latency increases.

christian: please let us know how it goes.

Christian wrote that the audio coming from JackTrip is clean. If that's really the case, then the buffer or resampling issue must be on the side of the machines running zoom...

Marcin

[Christian Fritze]

Thanks Marcin & Synthia - some new things for me to experiment with. In the mac setup I am using an aggregate device as you describe - I've got my (USB) mic set as the clock source, blackhole has drift correction on. Will pay attention to trying different combinations, as well as the frame/buffer/mono settings Synthia describes. 

[Christian Fritze]

Marcin & Synthia

Thank you for your ideas. After a few weeks break, our group got together again last night for a rehearsal. I increased the Frames setting in qjackctl and we had none of the dropouts/clicking in the zoom pipe! We had 22 people in JackTrip and 80 in Zoom - slightly lower than last month - but I think the frames setting made the difference. Hooray!

[Synthia Cynthia Payne]

Thank you for making my day and sharing your joy! The beauty of changing
the buffer/frames is that the network conditions change from one time to
the next, and the setting today might not be the setting you'll use next
time. Keeps you on your toes, and it's fun to see how different settings
change the quality and latency. Have fun!

kudos!
synthia

> <https://github.com/ExistentialAudio/BlackHole/discussions/27>).

>
> When using multiple devices as an aggregate device, their clocks
> either need to be synchronized (in some way, external devices
> can be synchronized with a digital connection like ADAT or with
> WordClock), or one of the devices needs to be used as the
> primary clock and other device(s) need to be resampled according
> to that clock (this is the "drift correction" feature). If

> that's not done, /problems will ensue/ (buffer under/overrun on

> input or output, and/or drift in recorded tracks).
>
> When using the built-in soundcard for input and output, even
> though they present themselves as two different devices,
> their clocks do not need to be synchronized (if they're set to
> the same samplerate), since they do take the clock from the same
> hardware source AFAIU. But when using e.g. built-in soundcard as
> input and USB soundcard as output, or virtual soundcard as input
> and physical soundcard as output, they have no way of being in
> sync and one of them should be resampled ("drift correction").
>
> (In case that's not clear already - the "clock source" in the
> aggregate device's setup should be set to the device that does

> /not/ have the drift correction checked)

>
> One thing that's still a mystery to me is that the drift
> correction (i.e. resampling) seems to be automatically applied
> in most cases when using different devices as input/output e.g.
> in zoom - at least on macOS I can typically use a different
> device for input and output and that works fine for me. However,
> I always feel suspicious about it and when dropouts like
> Christian's occur, I'd try to manually enforce resampling when
> mixing the input and output devices.
>
> and I've been listening to it again, and yes, those are
> simple dropouts
> and likely the buffer size like Marcin said. So increasing
> the number of
> buffers (or frames as it's called in JACK) will likely
> smooth things
> out, buuuut the tradeoff is that latency increases.
>
> christian: please let us know how it goes.
>
>
> Christian wrote that the audio coming from JackTrip is clean. If
> that's really the case, then the buffer or resampling issue must
> be on the side of the machines running zoom...
>
> Marcin
>

> --
> You received this message because you are subscribed to the Google
> Groups "jacktrip-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jacktrip-user...@googlegroups.com
> <mailto:jacktrip-user...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jacktrip-users/fac26389-2106-4a3e-b47c-04f275166398n%40googlegroups.com
> <https://groups.google.com/d/msgid/jacktrip-users/fac26389-2106-4a3e-b47c-04f275166398n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Christian Fritze]

One more update. When using a windows computer with JT Virtual Studio device:

JTVS - focusrite - usb_cable - laptop

 where zoom is using that usb input as mic in order to feed sound into zoom, we eliminated the stutter/gaps/clicks in zoom by using the usb2 port on the computer instead of the usb3 port. Fits with the idea that the signal from JT was overwhelming the Zoom software. 

[Marcin Pączkowski]

Glad you got it to work.

I'd like to add one comment:

Fits with the idea that the signal from JT was overwhelming the Zoom software. 

I don't see how using USB2 vs USB3 port could make "the signal from JT overwhelm[ing] the Zoom software".

If the solution is to use USB2, then the issue might be that the drivers/device was not behaving correctly under USB3, or there was some other issue with USB involved.

The only reason I'm pointing it out is to avoid leaving possibly inaccurate information in the thread and others picking it up. This is by no means meant to criticize anyone in any way - thank you Christian for sharing your solution!

Marcin