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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx https://lists.linuxaudio.org/listinfo/linux-audio-user
