[sf-lug] Switch meeting from Jitsi to Zoom

[Rick Moen]

Michael, suggest http://www.sf-lug.org/ front page have 'Tip: It best to
use Chromium/Chrome or 
<a href="https://en.wikipedia.org/wiki/List_of_web_browsers#Blink-based">relatives</a>'
if SF-LUG continues to use Jitsi Meet.


----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Sun, 6 Sep 2020 17:25:11 -0700
From: Rick Moen <rick at linuxmafia.com>
To: [a member]
Subject: Re: [sf-lug] Switch meeting from Jitsi to Zoom
Organization: If you lived here, you'd be $HOME already.

Hi, [member]!

Quoting [the member]:

> I made the suggestion, and I am using windows/10 and zoom often with
> no issues

Well, good.  Maybe SF-LUG will be happier with Zoom.  It's good to know
that switching would help at least one person.

> I don’t know the browser or the specific issues other than unable to
> connect via wireless as well as not having the camera work.  Also
> there was an echo issue when someone talked and a 10 second delay
> while speaking.

For the record, here's what I was talking about:

Jitsi Meet (which Bobbie keeps erroneously referring to as 'Jitsi') uses
the IETF's WebRTC protocol as the A/V transport.  Some browsers don't
even attempt to do WebRTC, especially older browsers.  The best Web
browser support for WebRTC is consistently reported to be provided by
the Chromium Web browser and its proprietary offshoot, Google Chrome.

A number of other Web browsers based on Chromium's 'Blink' engine, such
as Microsoft Edge and Brave Browser, are probably really good, too:
https://en.wikipedia.org/wiki/List_of_web_browsers#Blink-based

It's reported that _recent_ Firefox versions have good WebRTC support,
but only the recent versions.


The 'not having the camera work' problem I would guess is a standard
teething problem with local system security.  The first time you connect
from a Web browser to join an A/v session that needs accss to the
microphone or webcam, you typically need to give permission to the
browser, i.e., there's supposed to be a dialogue that says something
like 'A Web page on site meet.jit.si wants to connect to the microphone.
Give permission y/N?'  And likewise for the webcam.


All of the above are things that, frankly, the SF-LUG people ought to
have helped you with, but SF-LUG tends to really badly suck at helping
people solve technical problems.  But for the record, both of those
matters -- browser WebRTC support (the reason why Chromium/Chrome is
best) and giving security permission to connect to your microphone and
webcam -- are matters we've gone over and over and over.  SF-LUG 
should have walked you through that.

'Unable to connect via the wireless':  Not a complaint, but I have
insufficient information to help on that -- but whatever this was would
logically affect any A/V technology exactly the same, and is a separate
problem.

'Echo issue when someone talked and a 10-second delay while speaking':  
Probably one participant had a feedback problem, on the participant's
local computer, looping sound back from the loudspeaker to the
microphone.  This happens on Zoom, too -- and is a problem unrelated to
the choice of A/V technology.

The root cause of _that_ problem is basically people using loudspeakers
and microphones badly because they are novices at videoconferencing, 
e.g., they are using a really crummy laptop whose speaker and microphone
are practically adjacent.  A _careful_ participant would join a
videoconference using earbuds / headphones rather than the PC's built-in
speaker.  If everyone on the conference does so, then this syndrome
cannot occur.

I've been at an SF-LUG online meeting where some new person joined and
immediately there was a sound-feedback problem -- because that person
committed the aforementioned basic mistake of using a cruddy
speaker/microsphone setup and _not_ using earbuds/headphones.  This was
the first one where Bobbie had finally figured out how to join us, and
she (irrationally) immediately guessed that _my_ laptop was the cause.
(It was not.)

The interesting bit:  Nobody there tried the utterly obvious way to
identify which participant was sending the feedback signal:  You mute
for a few seconds each participant in turn, starting with the most
recent person to join.  The moment feedback goes away, that's the person
sending the junk audio signal, and you tell that person 'Please leave
yourself muted except when you need to speak, and please consider using
earbuds rather than a loudspeaker that can loop immediately around to
your microphone.'

Anyway, it's a Videoconferencing 101 problem, that should have been
dead-simple to solve, but, hey, this was SF-LUG, so they didn't even
figure out how to start.  Instead, Bobbie went with 'Make a bad guess
based on zero evidence that the highly technical guy did it.'

I hope that helps.


----- End forwarded message -----