Simple silence suppression for voice

[haakon]

During a voice call, Pidgin now sends constant audio traffic, even when there is silence. Especially on slower connections, this can waste considerable amount of bandwidth by transmitting nothing but ambient noise.

I used peak level data from GstLevel? in the input branch of media pipeline to control a GstValve? put between audio source and Farsight confbin. Whenever the peak drops below defined threshold, the valve gets closed, when sound level reaches above the threshold, valve opens again. This effectively blocks sending data over network in the silent periods and in my tests this simple method worked quite well.

Silence threshold might need to be fine tuned (or switched off at all) depending on microphone hardware and/or the noisiness of surrounding environment. I will propose an user interface for this in a separate ticket.

Future improvement can be adding support for comfort noise (RFC3389), as the line now stays completely mute when suppression is active, which can be a bit distracting.

I made a tiny change in level parameter that is passed to PurpleMedia?'s "level" signal handlers. The value converted from dB to percent was multiplied by five. Searching through source code history seems this was done to make the value variation displayed on call dialog level meter widgets look bigger. I think it is better not to confuse future developers and pass the unmodified percent value to the handler and multiply only in gtkmedia.c: level_message_cb() where it has reason.

[rekkanoryo]

If you're submitting a patch, the ticket should be a patch ticket, not an enhancement or defect.

[haakon]

For GUI allowing users to tune silence threshold see #13182

[rekkanoryo]

In looking at this patch, I'm a bit concerned that removing the multiplication may be something that we should wait until 2.8.0 or 3.0.0 for, since it's technically a behavior change. I may be wrong on that. I'm just concerned that if that multiplication is removed, any downstream libpurple frontends may see different behavior than they did previously and it may not be expected.

Feel free to call me an idiot or convince me that it doesn't matter. After all, I don't muck about in VV stuff; I'm just the monkey that commits patches on occasion :)

Assigning this to darkrain42 just to see if he'll give a quick opinion on it.

[BigBrownChunx]

Silence suppression can cause issues on some SIP (possibly other protocols too?) setups and should be optional per-account.

[haakon]

Replying to BigBrownChunx:

Silence suppression can cause issues on some SIP (possibly other protocols too?) setups and should be optional per-account.

Make-silence-suppression-optional-per-account.patch should implement this request.

[haakon]

Fix segfault when protocol plugin can not be found

[darkrain42]

I'm not totally keen on the UI (but I say that not really having a better idea)

[rekkanoryo@…]

(In [fb4d2b014576462db99d919dea15fbed03f1f48a]):
Credit where due. Refs #13180.

[jakub.adam@…]

(In [36f7981726410932b6262c6e29dfa937447f7779]):
Make the simple silence suppression stuff optional per-account. Fixes #13180.

[rekkanoryo@…]

(In [00d82ac80e3aef1bae2cc576f8f909c224c576b4]):
Credit where due again. Refs #13180.

[ocrete]

You don't want to do that:

1. Codecs like speex do it automatically for you and produce CN, but you have to keep giving the encoder packets so it can do its magic 2. you want to be careful about silence supression because of Wiress MM extensions... if you wireless card and router support that you will not get incoming packets fast enough unless you keep on sending 3. If you do silence suppression without CN, then you will hear a "click" or a "pop" every time you start/stop sending and it degrades the perceived voice quality quite a bit 4. Voice is really low bandwidth anyway and its only the maximum bandwidth that matters