Choopy audio on low bandwith networks whereas Whatsapp works fine

[JsBergbau]

• [x] I have searched open and closed issues for duplicates
• [x ] I am submitting a bug report for existing functionality that does not work as intended
• [ x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
• [ x] This isn't a feature request or a discussion topic

---

Bug description

One phone has reduced bandwith to 32 KBit/s, the other phone is connected to 100 MBit/s Wifi. When calling a conversation is not possible because audio is very delayed and choppy. Calling with Whatsapp gives fine audio quality, no delay and no choppy audio. When both devices are in the same Wifi there is perfect call quality, so it is just a bandwith problem.

Steps to reproduce

• Reduce bandwith to 32 KBit/s like the messaging option from Congstar provides on one phone or some Wifi-APs that support limiting speed of some devices.
• Call with another phone which has enough bandwith
• Try to have a clear conversation

Actual result: Audio is very delayed and choppy. Expected result: Clear audio quality as Whatsapp provides in that situation.

Screenshots

Device info

Device: Samsung Galaxy S10 Lite Android version: 11 Signal version: 5.2.3

Link to debug log

I don't think this needs a debug log. I've made this test already month before with same result, so it should be easy to reproduce.

[fernando-villalba]

There is a new setting "Use Less Data For Calls", you could try turning this on when on cellular network and see if this is still an issue?

[JsBergbau]

Sadly still very choppy when enabling "Use Less Data For Calls" for Wifi and cellular networks. Even when in addition turning this setting on the second phone which is in Wifi, there is a long delay, very choppy and no real call possible. Cross-checked again with Whatsapp. Good call quality despite reduced to 32 kbit/s.

[sobsan]

I have exactly the same issue. Calls are simlpy impossible. Again, with Whatsapp there is no problem at all.

I also tried the "use less data" option and also tried toggling the "relay calls over signal server" setting. I am also limited to 32kbit/s both up and downstream.

Is it technically possible to automatically reduce the call quality to adjust to the bandwidth available? Are there other ways to reduce data consumption (compress maybe)? I think there might be many with limited data bandwidth depening on your location. Also those with their monthly data consumed have a reduced speed for example of 64kbit/s down and 16kbit/s up. Personally I prefer having the ability to make calls over the quality of the call.

[Flexmaen]

Impossible calls here too, also very choppy, even with 10mbit/s. Might be a different problem than bandwith?

[Classic298]

I too have choppy calls with huge lags and terrible audio quality. Unbearable. Even with a good internet connection!

[tbertels]

There's a post on Reddit suggesting Signal may be using TCP instead of UDP, which may explain these problems, is that a fact?

[JsBergbau]

It depends. Since some networks block almost all destination ports except 80 and 443 and especially UDP this approch can help user with user unfriendly configured firewalls.

have a tiny bit of VoIP experience, and I feel like it needs to drop down to a lower quality codec/bitrate in these situations to ensure packets get through on time.

Thats the main reason. Another codec should be selected that doesn't need so much bandwidth.

[Classic298]

Okay idk what changes but for a few weeks now signal calls are working perfectly fine for me now. They really didn't in the past though

Does someone else sill have issues?

[tbertels]

No problem here.

[JsBergbau]

Problem still exists. It maybe a little bit better, but it is still impossible to do a useful Signal phonecall when one of the participant is limited to 32 KBit/s audio bandwidth whereas with Whatsapp there is enough call quality to have a real conversation.

[alex-signal]

The calling team has been doing a lot of work in this area. Please try altering the bandwidth options in call settings if you haven't already. Otherwise, please post some debug logs here after a call and I can forward them to the calling team.

[tbertels]

Indeed, there's an option in the Android version (not on Desktop) in Data and storage: Call: Use less data for calls: Never/Mobile data only/WiFi and mobile data. With the description "Using less data may improve calls on bad networks". This means that:

• the call quality will be permanently lower even if the bandwidth is good
• the user has to enable this setting, even though this can happen to any user

Is this option there only for testing purposes? E.g. to check if it's useful to implement automatic bandwidth throttling on bad connections?

[JsBergbau]

Using lower bandwidth on mobile data and Wifi is already enabled. Did an experiment. Download this App https://play.google.com/store/apps/details?id=com.nisargjhaveri.netspeed This shows current network traffic. When phoning via Whatsapp and Wifi it show mainly something between 1 and 2 kB/s when there is silence. When speaking, data rate goes up to 8 kB/s (4 kB/s each direction). With Signal there is already there ~17 kB/s. So Whatsapp seems to use much higher variable compression algorithm than Signal. 32 kBit/s is 4 kB/s, so Whatsapp stays within the limits given by mobile phone company with the reduced bandwidth of 32 kBit/s, calling works with good quality.

With Signal and mobile data datarate goes even up to 10 kB/s, so provider even gives higher speed than officially granted but still it is a lot too small for Signal.

Both phones have set the option to reduce bandwith for mobile data and wifi even though it should be sufficient to do that on the phone with reduced bandwith.

[Flexmaen]

Maybe it also depends on how the call is rooted. I had problems calling from Austria to Germany or New Zealand with Signal while Skype worked fine.

[tbertels]

Both phones have set the option to reduce bandwith for mobile data and wifi even though it should be sufficient to do that on the phone with reduced bandwith.

I wonder if Signal manages to enable this low bandwidth mode. If it doesn't, there should be a message in the debug log (In Settings > Help). The message should be either handleBandwidthModeUpdate: could not update bandwidth mode or Unable to update bandwidth mode on CallManager based on 1 and 2.

By the way, while Signal is supposed to use the Opus codec, there's no mention of it in the code, though AAC LC can be found.

I forgot to mention that there's a mention of a bitrate of 32000 (I'm guessing bit/s).

I didn't find what the bitrate is supposed to be in "reduced bandwidth mode".

[JsBergbau]

Sorry for the late reply. I've checked the log. The string bandwi can't be found. So I guess low bandwith mode seems to be enabled.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[JsBergbau]

Problem still exists

[cody-signal]

@JsBergbau can you provide an updated debuglog? Preferably from the latest beta if possible.

[JsBergbau]

I have noticed another thing. Thats network traffic from Windows Ressource Monitor when Signal option is set to reduce bandwidth on phone (latest version from playstore 5.38.5) and using Signal Desktop (5.43.0) on PC.

So with reduced bandwith about 4 KB/s data is flowing. Without reduced bandwith about 8 KB/s, so about double.

This example is when both in LAN, but thats not the point. This data is constantly flowing, even with silence. When speaking datarate is rarely higher. With Whatsapp with silence there is significant less data flowing than when speaking. So that is another point that should be investigated.

[awaitlink]

This data is constantly flowing, even with silence. When speaking datarate is rarely higher. With Whatsapp with silence there is significant less data flowing than when speaking. So that is another point that should be investigated.

I think this is because Signal uses a constant bit rate for calls to protect against side channel attacks that can reveal spoken words.

[JsBergbau]

So then only issue remains that bitrate is too high. Since signal uses opus codec and it has great compression for speech, there should be an option to lower bandwith even further. I've tried with opus with --bitrate 16 --hard-cbr and the quality was still way better than normal phone audio quality. Bitrate 16 is 2 KB/s and should work then on low bandwith networks. Maybe there would be even an adaptive bitrate possible as whatsapp seems to use. With Whatsapp you can sometimes hear audio quality change while in call.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[JsBergbau]

Still an issue.

[Totorrr]

@cody-signal I guess this mostly needs a little testing, doesn't it? Would you actually benefit from a debug log here? I'm asking because my guess is that it would not help much, but I may be wrong.

Can you maybe try to lower the bitrate for calls, or even better, make the bitrate negotiable live so that it would be set to a lower setting in case of packet loss or excessive delay, and use higher bitrate otherwise?

[kermem]

Same issue here with calls, been going on for almost two years. No issues with WhatsApp and Telegram.

Enabling the "use less data for calls" option didn't help either.

[Flexmaen]

This is still open but I have to mention that I noticed that call quality significantly improved with some of the updates since then. For me Signal works fine for calling now.

[breversa]

I'm getting choppy audio on dual videocalls, especially when two people try to speak at the same time, even when both are on wifi, within the same country (France).

Both users use:

• Signal version 7.20.2
• /e/OS 2.4
• Fairphone 5

[tklebel]

I'm likewise experiencing very choppy audio, using a Fairphone 5, while WhatsApp is completely fine.

During a video call, I can understand the other side reasonably well (with some interruptions), but the other way around seems to be terrible.

Here is the debug log: https://debuglogs.org/android/7.33.2/bbd4f67b55d790db7a2a2022eb502462646c11b53b034b92cc804b7864bb0a83 The call in question starts at 2025-02-18 17:39:51.123

During the call, there are many errors:

[7.33.2] [2103 ] 2025-02-18 17:40:12.761 GMT+01:00 E timing.cc: (line 32): Playout delays set incorrectly: min playout delay (670 ms) > max playout delay (501 ms). This is undefined behaviour. Application writers should ensure that the min delay is always less than or equals max delay. If trying to use the playout delay header extensions described in https://***.com/src/+/refs/heads/main/docs/native-code/rtp-hdrext/playout-delay/, be careful that a playout delay hint or A/V sync settings may have caused this conflict.

Note that my WiFi suffers from bufferbloat (grade C-D on this test: https://www.waveform.com/tools/bufferbloat). Maybe this is of relevance, maybe not. Have not tested/compared over cellular.

Further note that using an iOS devide (iPhone SE gen2, iPhone XS) in the same WiFi network works without an issue.

[DaneEvans]

This remains an issue - particularly noted on international calls.

The delays get longer as the call goes on, and reset with a new call.