6 Jan
2021
6 Jan
'21
6:21 p.m.
On Wed, Jan 06, 2021 at 09:52:55AM -0600, Chris Caudle wrote:
My guess (only a guess, but I would be open to
discussion of ways to test
the hypothesis) is that changing the buffer size either reduced dropouts
in the jackd to browser interface (which I assume is probably pulseaudio
jack module, which is known to have some problems at low jack buffer
sizes), or the larger buffer size rippled through to the browser interface
and allowed the meeting software to process fewer buffers, reducing
dropouts in the meeting software somewhere, either browser implementation,
or server (if a central server was used rather than peer-to-peer), or at
the other end of the connection.
I don't know about other browsers, but Firefox supports jack natively
(cubeb is audio lib Firefox is using):
https://github.com/mozilla/cubeb/blob/master/src/cubeb_jack.cpp
The thing is that pulseaudio might be initialized before jack if
pulseaudio is found:
https://github.com/mozilla/cubeb/blob/master/src/cubeb.c#L30-L74
To use a specific driver backend, one can go to about:conig and add
media.cubeb.backend as a string. As I'm on FreeBSD, my setting is "oss".
Maybe you can try different backends and find the one that suites you,
unless you really need JACK. Of course, if Firefox is not an option for
you for any reason, this is pointless, but you can at least give it a
try for testing purposes.
As most conferencing software is WebRTC based, it's by default peer to
peer (even Google services), so I wouldn't doubt the service that much.
Of course, if you're on IPv4, you're probably behind router (which means
NAT) and you have to use ICE servers (configured automatically by the
service like Jitsi). When I say ICE, I mean TURN and STUN, so if there's
a bottleneck, I would expect STUN/TURN to cause it.
Regards,
meka