From: "Valent@MeshPoint" <valent@meshpointone.com>
To: "Juliusz Chroboczek" <jch@irif.fr>
Cc: "Curtis Villamizar" <curtis@orleans.occnc.com>, galene@lists.galene.org
Subject: [Galene] Re: Gal?ne for bigger meeting (10-15 people) - problems and UX questions
Date: Mon, 20 Jul 2026 14:37:49 +0000 [thread overview]
Message-ID: <eme60e7d38-ff2b-4a7e-bde3-1cb6d9e7b8c9@meshpointone.com> (raw)
In-Reply-To: <87ik6age80.wl-jch@irif.fr>
[-- Attachment #1: Type: text/plain, Size: 4602 bytes --]
Hi Juliusz, Tim, all,
thank you very much for the detailed answers, this helps me a lot.
You are right, I dont know Galène good enough to say where is the
problem, and I don’t want to guess. So better I measure it properly on
the next test and bring you real numbers.
My feeling, maybe I am wrong, is this... with three or four people it
worked without any problem, so when ten broke everything it surprised
me. I would understand that fifty or hundred would cause issues... But
now I understand from you that with an sfu the server upload grows very
fast, ten cameras is already around ninety copies, not two or three
times more than four. So maybe ten is already a big jump. This is what I
want to measure, not assume.
So for the next test I would really like your help what to measure and
where.
I run the docker image, valentt/galene. Your faq says docker is not good
for the network. So what is the correct docker setup, is host networking
the right thing? Which udp port should I open with the new udp
multiplexing? And how do I make Galène show the real public ip and not
the private one from the container?
If I run relay test from a client and it fails, does this already mean
the problem is media and ice and not bandwidth? What should I look for
in the ice trace log?
Tim says I need around hundred megabit uplink. For some cameras on the
default send limit, how much server upload I need, and does simulcast
keep it under control? I will measure it with iftop during the test. And
the stats page, what does it show me per client, can I read it during
the test?
Your point about the client side being weaker. With ten or fifteen
cameras, how many people overload their own upload on the default?
Should I make the default lower for big meetings? Can one bad upload
spoil the room for everybody?
And kicked out under load, could this be the file limit too low inside
the container?
So my plan is, before the test I check host networking and the version
and the file limit. During, I run relay test, I turn on the ice log, I
read the stats page, I measure the server upload, and from each client I
collect the outgoing bitrate and the lost packets. Then I bring you the
numbers so we see together if it is docker network, server upload, one
bad client, or the browser.
About Firefox and DJ Stern, I understand, I will tell people to use
Chrome (although I used Firefox with no problem), and the raise hand
button I will fix like I promised.
I also like your idea of a test your microphone and camera button on the
login page. The camera can stay off by default, that is fine (I never
thought to turn it on by default, just to make sure it works before
joining in...), but people should be able to check right away that their
microphone and camera actually work, before they join. I think that
would really help the ones who click connect without reading the screen.
Thank you, I really want to make this work good.
Valent
Best regards,
MeshPoint Logo
Valent Turković
CEO
valent@meshpointone.com
www.meshpointone.com
On 2026-07-20T12:14:23+02:00, Juliusz Chroboczek <jch@irif.fr> wrote:
> The default could be set in the group definition. chat-only for
> lecture, camera+microphone for chat or meeting. This way the person
> setting up the group can make the decision based on how the group is
> used.
There are two different issues here.
First, there's whether the camera and microphone should be switched on
when entering a group. On this subject: I feel very strongly that Galene
should *never* switch on the user's camera or microphone without an
explicit action from the user. I also think that a user who enters
a group should be forced to lurk in silence for a few seconds before
they
are allowed to turn their camera on, so that they can check they are in
the right meeting.
For these reasons, switching on the camera automatically upon entering
a group is not something I'll implement in Galene.
The other issue is whether we should request the browser permission to
use
the camera and microphone at login time, or whether we should do it at
the
last possible moment as we do currently. The advantage of requesting
them
early is that joining the discussion has lower friction; the advantage
of
asking them later is that we don't worry the user uselessly.
I think the right solution is to have a button "test your microphone and
camera" on the login page that leads to a simple echo page.
-- Juliusz
[-- Attachment #2: Type: text/html, Size: 6438 bytes --]
next prev parent reply other threads:[~2026-07-20 14:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 14:19 [Galene] Galène for bigger meeting (10-15 people) - problems and UX questions Valent Turković
2026-07-16 16:28 ` [Galene] " Tim Panton
2026-07-16 17:24 ` err404
2026-07-16 19:38 ` Juliusz Chroboczek
2026-07-19 19:45 ` [Galene] Re: Gal?ne " Curtis Villamizar
[not found] ` <178450473448.1644.1354246601774709853@gauss>
2026-07-20 10:14 ` Juliusz Chroboczek
2026-07-20 14:37 ` Valent@MeshPoint [this message]
2026-07-20 16:03 ` Juliusz Chroboczek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eme60e7d38-ff2b-4a7e-bde3-1cb6d9e7b8c9@meshpointone.com \
--to=valent@meshpointone.com \
--cc=curtis@orleans.occnc.com \
--cc=galene@lists.galene.org \
--cc=jch@irif.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox