Trigger threshold for visual outline sound indication insufficient + lack of outline visibility

[Jerome-Herbinet]

My colleagues and I use Talk every day. Here's a statement that everyone agrees on.

In videoconferencing software, such as BigBlueButton, when a participant's background noise is detected, it's immediately obvious (the label with the participant's name lights up at the slightest noise), enabling the moderator(s) to spot the person concerned and ask them to do what's necessary, or even mute them until they need to speak.

In Talk, the white contour line is not sensitive enough and is only activated when the person is actually speaking. This lack of sensitivity may be intentional on your part, and is in line with speech time detection... except that, in the real world, with what I've just described, it has the perverse effect that video meetings are easily polluted by background noise without you being able to tell who it's coming from.

Is it possible to set a trigger threshold as low as possible, independently of the threshold used to measure speaking time?

I'd also like to take this opportunity to point out that the current white outline is not visible enough in my opinion, especially as it also looks too much like the white outline when the cursor is hovered over the person's block. I think it should be different, for example thicker, with a possible animation suggesting a sound flow ... or a microphone icon over the block (z-index), whose color (of the icon itself or of the background) would change to a clearly visible color.

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

[Jerome-Herbinet]

@nextcloud/designers

[nickvergessen]

The problem is not only the speaking time, but also whether the camera switches to the person when you are on the speaker view.

But I think it makes sense to decouple both things a bit and have the white border earlier/longer then the speaker focus/time.
I guess it's rather complex to achieve thou? cc @danxuliu

[danxuliu]

I guess it's rather complex to achieve thou? cc @danxuliu

Currently we are using the default volume threshold in hark, which is what triggers the speaking and speakingWhileMuted events. However, the volumeChange event is triggered on every poll event with the current volume and threshold, so we could send some additional signaling messages, for example, mumbling and stoppedMumbling (or however we want to call them, just an example) when there is some sound but it has not reached yet the speaking threshold.