Lorenzo Sutton <lorenzofsutton(a)gmail.com> writes:
That all makes sense and thanks for the tips and kind
offer... There
is the 'speed of light' factor after all.
Don't overestimate it, at least in Europe. If we reduce speed of light
to a third (to account for back-and-forth and probably overoptimistic
repeater performance), 1ms is good for 100km. That doesn't bode well
for world-wide jamming, but with countries as small as those in Europe,
at least nationally it's workable.
Thing is.. _I_ amd the student (blush..) here, so the
idea is not to
over-bourden my teacher who is probably already having to cope with
setting-up the calls, schedules etc. :-)
Ah, ok. Of course, "used to compensating latency" is not really a
specific "teacher" skill unless we are talking latency-heavy instruments
like some organs.
I would be interested to see if I can actually get my
band to try this
out since it's months we can't play together live :-(
Looks like I need to work on subtitles for
<https://youtu.be/Vn1f70IH-Es> (my talk on Jamulus at the Chemnitzer
Linuxtage last Sunday, in German). Or maybe start by translating at
least the slides.
Software:
- Jack
- Zoom H5 shows 4 inputs in jack: the L/R mics and the inputs 1 and 2
Oh, can you
just put the headphones right next to the mics (makes
astonishingly little difference in comparison to direct connections) and
use jack_iodelay for measuring out the latency of the H5 with your
settings?
What exactly would you like me to measure? Roundtrip latency of _my
own_ signal when using Jamulus, or...?
Not involving Jamulus at all. Just the raw mic-to-headphone delay when
using jackd at your usual settings (likely 128 or 64 samples per
period).
Numbers are
surprisingly hard to come by for any audio interface.
So true...
Lorenzo
--
David Kastrup