Highlight choir singer that is creating feedback

[kezzy1966]

Please could you consider introducing a new feature to some how to put a mark a choir singer's slider who is creating feedback or their audio is distorted.

I know this is a lot to ask but Jamulus is now being used by choirs over 20-30+ singers. Some singers are not able to self diagnose there audio. It would be very handy if someone could identify them causing a problem and can flag up a mark, '?' or 'x' that can appear on their slider. Others could then drop that slider.

I am very aware Jamulus was not initially designed for the large choir market and what it can do is quite amazing.

[chrisrimple]

Seems like this could be similar to how Mute works. Maybe there's a "Mark" button for every fader, and anyone clicking it causes all clients (on that server) to show that fader's name in bright red (or similar). "Mark" settings are NOT retained between sessions and not saved in the INI file (unlike Mute and Solo). Disconnecting from a server or quitting Jamulus should clear all "Mark" settings.

[ann0see]

The question is how you detect feedback. Just by clipping? We could maybe check if a user is clipping all the time and then highlight the slider/name?

[kezzy1966]

Detection of feedback is normally by luck, trial and error. Especially on big choir sessions. Perhaps wait for a quiet bit and see what activity line/fader is still showing some audio. Then push the slider up of that person. It can be difficult though. The point is not everyone in a choir can do that but someone not singing / tech support can do and flag it up.

[ann0see]

Hmm. But how can Jamulus (Software) do this or would you like a flag named "clipping" set by somebody (this chould then also be done with the chat function)

[corrados]

Jamulus supports a clipping indicator already. If a musician has a loud feedback, the clipping indicator should be triggered and it should be easy to identify the channel.

[kezzy1966]

Hi Corrados,

I'm not talking about clipping as that should be immediately fairly obvious by seeing their vu meter line shooting up.

I more concerned with someone causing 'bubbling' and general distortion to their audio. Perhaps due to their 'frames' not set correctly causing xruns or jitter buffers being set too low.
It is not immediately obvious to pin point the individual - even on a small group.

Still a great system though.

[ann0see]

Ah. So it's not feedback in terms of "microphone records sound of speaker" but "this person has audio issues". I think we had a discussion about something like this somewhere #762 (comment) #762 (comment)

[gilgongo]

I think we had a discussion about something like this

The question raised in this ticket is interesting because it's related to my general question on #762: is there a relationship between some programmatic condition (a buffer underrun, packet ordering, or a certain ping time, say) and a specific type of audio distortion?

I get the impression that Jamulus could tell a "normal" packet stream from an "abnormal" one (and that there might be an acceptable level of abnormality). In which case Jamulus could indicate a problem as per this feature enhancement request.

But (and this is the subject of #762 for me at least), letting somebody know what action to take (adjust buffers vs reduce quality setting, say) would not be possible because (for example) while a buffer overrun might cause "burbling", that burbling might also be caused by poor ping time or lack of bandwidth server/client side. Is that right?

So - just to get this clear: assuming the point of this ticket is simply to highlight a person whose signal is degraded, then that might be useful in allowing you to easily mute the offending signal. But it would not allow you to tell the person at the other end what to do about it.

[kezzy1966]

"the point of this ticket is simply to highlight a person whose signal is degraded" - yes that what I am asking for.

It would be too difficult to diagnose the actual problem but at least

1. everyone else is alerted that channel might be the problem (+ maybe choose to drop that fader)
2. the person causing the problem can then run through a test procedure

[gene96817]

It would be difficult for a simple algorithm to detect feedback. Jamulus already indicates (latches) a clipping condition.
We could detect when a channel is "too loud" (clipping for a "long" time) and suppress it so that it doesn't make the session unusable for the other musicians. Suppress could mean turn the volume down to something very low (5%?) so that someone could troubleshoot that channel with continuous sound. Suppress could be something more drastic (e.g. kill or disconnect) but then it will be harder to troubleshoot.

@gilgongo We can do more analysis on "abnormal" traffic if the packets are numbered. Then we can do things like (1) detect out of order packets, (2) detect erratic interpacket times, (3) detect a long delay and then see all the late packets causing xxxx, etc. This is interesting for understanding when bad Internet transport is affecting our sound. This could also be a rabbit-hole.

I think numbering the packets and collecting interarrival rates in a log could be really helpful with minimal processing. This still does not help in creating code to detect feedback.

Is it possible some people on this thread are using the term feedback to mean some other audio defect?

[gene96817]

Detecting feedback will take the same kind of code as eliminating feedback.
Let's clarify this thread to dealing with a user that is overwhelming the session with too much sound.
Then we can decide what conditions of "too much sound" are bad and need/deserve automatic suppression.
Some degree of automatic suppression will be needed, especially for a naive or inexperienced user that will respond slowly to muting themselves.

For fans of loud music, perhaps the threshold needs to be adjustable (i.e. triggering volume and duration or even disabled). Acoustic musicians probably want a lower threshold. People with tinnitus probably need a lower threshold too.

[ann0see]

I think we should open another thread for feedback detection.
#801

[kezzy1966]

I just wanted to clarify a couple of points from my choir experiences and observations relating to this:

i) feedback does not need to be excessively loud. It can be a whistle that rises, falls then disappears for a while. Maybe only reaching 1/2 or 1/3 up on the vu meter. When it is very loud it is very easy to identify and you can pull that slider down. Very loud feedback is not the problem here.

ii) Audio 'distortion' like audio 'bubbling' is when the singer's voice intermittently breaks-up. It maybe hard to identify which singer/channel is causing it as may come and go. I presume it comes from high xruns/ incorrect buffer settings, client kit becoming faulty.

I am just requesting a way for a large group to mark/ query/ identify the individual that 'might be' causing audio distortion. That person could perhaps connect to a small test server and check their own audio.

[gene96817]

@kezzy1966 Thanks for the details.
The first symptom sounds like feedback at the user's station with the mic picking up their speaker output. This can be detected by an echo cancellation algorithm.

The second symptom could be at the user's station with late task processing OR from network delays delivering late packets OR dropped packets. My suspicion is intermittent burst of late packets. I assume the user has already closed as many of their processes/windows as possible. I believe this class of problem needs some diagnostics using packet numbering. I guess we could build a detector just monitoring the audio output but then we need to detect discontinuous audio waveforms. Maybe this kind of monitoring is easier than I guess but I don't know any "off-the-shelf" components to use.

[38github]

I would love an automute of anyone clipping. This would make them more aware of their gain staging. Lately there have been too many incidents where people of inertia just crash amazing jams.

[ann0see]

I think @JohannesBrx is working on something similar

[gilgongo]

I've just asked a question about whether this feature is needed or not now that client may be able to auto-mute on feedback: #1179 (comment)

[gilgongo]

OK as per #1179 (comment) I'll move this to a discussion on that point re. messaging to others or not.