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!
> 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...