I have:
When doing an audio call on Speaker mode in the new Voice/Video call beta enabled, you can hear your own voice clearly reflected through the microphone. This causes a rather high level of annoyance as you hear your own voice, with a double round-trip time in between, making it a very sad communication companion that constantly interrupts you when you speak.
Actual result:
Annoyingly noise of your own voice
Expected result: Effective echo cancellation on the remote side that cancels out the noises from the speaker against the microphone.
Not applicable
Device 1: Fairphone 2
Device 2 Nexus 5x
Android version: 7.1.1 and the current fairphone (5/6 something?)
Signal version: Pass.
Not applicable.
Do you observe this on both ends?
Just to be sure: are the devices isolated from each other / in different rooms?
Some devices have broken hardware AEC. If you hear echo, the problem is on the other end (that device isn't canceling out the speaker audio from the microphone input), so we'd need information about the device on the other side.
It was observed on one end, devices are isolated from each other with a nice wide swath of ocean and some land.
The device that would be missing AEC would be the Fairphone2, which is also, sadly, the one that I don't have here to get specifications & logs from.
I have a Fairphone 2. I will try to reproduce this issue in the next few days.
Just tested it. I heard a very clear echo speaking into device XU -> FP's echo cancellation failed. I heard the echo cancellation working speaking into device FP -> XU's echo cancellation works fine. There is always some soft noise coming from FP's earphone but directly after I spoke a word into FP this noise was somehow disturbed. I interpreted this as working echo cancellation.
tl;dr I can reproduce this issue and it's device FP's fault.
Device: Fairphone 2
Android version: 5.1.1
Signal version: 3.29.6
Device: Sony Xperia U
Android version: 4.4.4
Signal version: 3.29.6
Thank you for verifying this. Can you follow up with upstream fairphone?
On Fri, 17 Feb 2017, 18:02 FeuRenard, notifications@github.com wrote:
Just tested it. I heard a very clear echo speaking into device XU -> FP's
echo cancellation failed. I heard the echo cancellation working speaking
into device FP -> XU's echo cancellation works fine. There is always some
soft noise coming from FP's earphone but directly after I spoke a word into
FP this noise was somehow disturbed. I interpreted this as working echo
cancellation.tl;dr I can reproduce this issue and it's device FP's fault.
Device info FPDevice: Fairphone 2
Android version: 5.1.1
Signal version: 3.29.6
Device info XUDevice: Sony Xperia U
Android version: 4.4.4
Signal version: 3.29.6β
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/WhisperSystems/Signal-Android/issues/6241#issuecomment-280706923,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABmI5i6ZzRlqpZSWtWNcB7Rd00LKa-LWks5rddK7gaJpZM4MDosn
.
I tested the dialer app with my landline phone and I hear no echo speaking to my landline phone. But maybe the landline phone can also do echo cancellation for the other side...
Can you follow up with upstream fairphone?
I just revived this thread: https://forum.fairphone.com/t/echo-with-google-hangout/15745
@FeuRenard I can try blacklisting the fairphone from hardware AEC in the webrtc code, can you give me the fairphone2's "ro.product.model" string?
In settings -> about phone -> model number it says "FP2". Is this what you want? If not: From where can I get this string?
Yeah I think that's it
@FeuRenard can you try this test apk on your FP2 and see if that helps?
I tried. Good news: echo cancellation seems to work with this apk. Bad news: Fairphone 2 reboots after a couple of seconds.
Hah, what!? Just... reboots?
Yes. 4 out of 5 times I tried it rebooted. I sent you logcat of the final seconds before reboot via e-mail if you are interested.
@FeuRenard can you explain how to install this apk (in the community forum for example)? Can i run it alongside my normal signal installation? Then I could try and test it on my Fairphone 2 tomorrow...
Sounds like the fairphone has some issues. Either they need to fix the AEC or they need to fix the crash, I don't think there's anything else I can do.
My redmi note 3 pro is displaying the same issues: my conversation partner is complaining about echo, but on my end everything is fine.
If you push your commits from your testapk somewhere i can give it a shot.
getprob
says:
[ro.product.board]: [MSM8952]
[ro.product.brand]: [Xiaomi]
[ro.product.cpu.abi]: [arm64-v8a]
[ro.product.cpu.abilist]: [arm64-v8a,armeabi-v7a,armeabi]
[ro.product.cpu.abilist32]: [armeabi-v7a,armeabi]
[ro.product.cpu.abilist64]: [arm64-v8a]
[ro.product.device]: [kenzo]
[ro.product.locale]: [en-US]
[ro.product.manufacturer]: [Xiaomi]
[ro.product.model]: [Redmi Note 3]
[ro.product.name]: [cm_kenzo]
Despite it saying redmi note 3 it is a redmi note 3 pro, which has slightly different hardware.
Just for the record:
My conversation partner even complains about hearing herself while none of us uses the speaker mode. She uses an iPhone SE and I use a Fairphone 2.
@FeuRenard interesting. Sounds just like something I experienced when calling a Xiaomi Mi4 (ro.product.model = "MI 4LTE"):
We tried every combination of the three blacklists in WebRtcAudioUtils.java. The minimal change required to make it work properly was to add "MI 4LTE" to both the OPEN_SL_ES
and the AEC
blacklists. Tested in a 40 minute video call with speaker mode on and off, no problems.
If you're interested in investigating this further, I could provide you with test builds of the AppRTC demo app with and without your model blacklisted.
I've noticed similar echo issues with a Samsung S5? Is there any similarity between the hardware on these devices?
@skulumani what exactly are you seeing? You're hearing an echo when you do a WebRTC call to someone who has a Samsung Galaxy S5 and they enable speaker mode?
ftr: i too was not using the speaker mode, but the other party complained about echo.
I (Moto X 2013) call a friend (S5) and I experienced an echo of my own
voice.
We're both using the new beta calling feature and from this thread it seems
to be a function of the S5 rather than my moto x.
Another thing is that the echo is almost the same volume as the incoming
audio. I suppose it's a function of the volume of the speaker of the S5.
We're both using the standard ear piece rather than the speakerphone. Only
I hear the echo while the friend does not. I can do more testing and
submit logs if it'll be useful.
Is there any more information that might be useful. For example, I can do
some research into the hardware of the Samsung and Fairphone. I can get
debug logs or try and use the test apk from above.
On Wed, Mar 1, 2017, 16:54 haffenloher notifications@github.com wrote:
@skulumani https://github.com/skulumani what exactly are you seeing?
You're hearing an echo when you do a WebRTC call to someone who has a
Samsung Galaxy S5 and they enable speaker mode?β
You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub
https://github.com/WhisperSystems/Signal-Android/issues/6241#issuecomment-283482906,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFBaZswwERaib6f7si88sQ5OSc0UqkgDks5rhej9gaJpZM4MDosn
.
By the way @moxie0, I have an s5 I could test on if needed.
We're hearing echoes since video calls were added, too. (When video calls were in opt-in beta, we enabled it for testing, heard the echoes and disabled it again.) Before, we didn't hear any echoes at all.
Both devices are Wileyfox Swift (and the echoes can be heard on both ends).
I am still getting echoes (Pixel Phone to Pixel Phone). One thing that I noticed is that I have speaker on when the video call starts. If I turn speaker off it mitigates the echoing (but doesn't make it go away). With speaker off it is still loud enough for me to hear the other person (in a quiet room). Not sure if it's being tested with/without speaker.
Seems like we should get more aggressive about adding devices to the hardware AEC blacklist. @haffenloher I'm surprised that OpenSL was a contributing factor with echo.
Pixel, S5, Redmi Note 3, and Xiaomi Mi4 should be taken care of in 4.1.0
@moxie0 i know, it's really weird. But then again, the symptoms were really weird too (super-strong and clear echo even with headphones).
Anyway, cool that you're adding more phones now! I did some tests with an echo-producing Samsung Galaxy S4 Mini and can confirm that adding "GT-I9195" to the hardware AEC blacklist fixes the echo.
Also noticed echo with a Sony "Xperia SP" (apparently that's the model string), but didn't have the chance to test blacklisting it yet.
This is kind of crazy, are there any devices that do have functional hardware AEC?
So far I only saw it working with three devices :/
a pattern I noticed is that all the people I had echo problems with were running CM / LineageOS. Could that make a difference? Do any CM or Lineage users have working echo cancellation?
Oh yeah that could definitely make a difference. I'd only want to make changes to the AEC blacklist if it's a documented problem on stock.
I have experienced this problem with the recipient having an LG G3 running stock Android. They do not report that they can hear an echo the other way round.
I have had a webrtc-call with a different contact yesterday (i am still running 3.30.1), and the other party did not hear any echo. Are you really sure this is always only about hardware AEC on my end?
It looks like we can make these changes at the application level, so I've reverted 4.1.0 back to stock M57 and added the blacklist info into the initialization logic. If anyone with an affected device can confirm these application-level changes are still effective that'd be great.
I also added the LG G3 here.
Can't do the blacklist test,
but just called a Galaxy S7 (stock OS) with massive echoing.
My Sony Z5 Compact behaves nice and echoless
Both Signals are 4.0.0
Would it be worth adding an advanced settings option to force software based AEC (with a suggestion to report if it fixes the echo problems in the description) to make testing which models require this easier?
@flungo Might be a good idea but most people won't understand that the setting should be toggled by the person they're calling, not the person that hears the echo.
Also, I added Samsung Galaxy S7 and Sony Xperisa SP to the blacklist.
Should hardware AEC just be shut off to avoid keeping a blacklist until time for further research?
Tested several android phones with Signal 4.1.0:
Motorola Moto X 2014 (XT1095), stock 6.0 - OK
Motorola Moto X 2014 (XT1095), LineageOS 14.1 (7.1.1) - echo
Wileyfox Swift, stock CyanogenOS 13 (6.0.1) - echo
@moxie0 We definately need at least an advanced option to manually enable software based AEC. But forcing software AEC for all phones looks like the simplest solution for compatibility.
The OnePlus X needs to be blacklisted too. Tomorrow I'll have access to the device and check its ro.product.model.
On my device (Honor X5 on lineageos) I notice at the end of /system/etc/audio_effects.conf the following message:
#
#
And I suppose if I add something like the following to this file, I might enable the hardware acoustic echo cancelation..
pre_processing {
voice_communication {
aec {}
}
}
After update Pixel to Pixel seems good to go. Thank you! @moxie0
(These devices are running stock android btw.)
There: #6465. It seems that the hardware AEC is mostly broken, it should probably be enabled on a whitelist basis, or just disabled.
I think that static blacklist/whitelist solutions isn't right for this problem. It would work with iOS, where you have only several supported phones, which can easily be tested and re-tested after major OS updates. But with Android we have thousands of phones, many of them receive major OS updates and needs to be re-tested (becase major update easily can break or fix something), and some of them may be used with custom software (which similarly can break or fix something).
For example my situation: I have two Moto X 2014, one is used with stock software with working hardware AEC (rare case), and another with custom software with broken hardware AEC. I want to use Signal for voice calls between them. How could be this possible with only static blacklist/whitelist? This phones has the same product model string (XT1095).
Probably you want to have working Signal on all android phones with all their diversity and not only on dozen "compatible" ones, which is listed in blacklist, right? BTW, you can hear echo even without speaker mode. So this regression really hinders the use of calls in Signal.
Possible solutions:
Personally I can use any of the three proposed solutions. But taking into account the diversity of android phones and the efforts required to maintain blacklist, I think the last two solutions is better for this case.
@moxie0 What do you think?
@lantsem
I agree your option 1 seems unworkable, but I suppose a whitelist would be manageable.
In the longer term I can imagine a fourth possible solution in which when echo or feedback is detected (automatically) at one end of the conversation, the client sends a request for the other side to switch to software AEC.
Nougat-MR2 (7.1.2) was released. This should provide a solution for Nexus 6P.
I believe I'm being hit by this between two bacon phones (OnePlus One) in a worse way than reported, not only does it echo, but when video is triggered it causes the typical screeching loopback noise as when you have two phones next to each other with speaker on. This happens regardless of the proximity of the phones (meaning that I confirmed that it happens when they are not next to each other and are too far away to be caused by loopback interference). Unfortunately now that the new WebRTC calling is out of beta and the old method deprecated, I can't really effectively privately call the only person I use private calling for. :(
Signal 4.2.4 on both ends
@jp8
Yes, dynamic adjustment looks like possible solution for this problem. And webrtc M57 already has audio processing component that detects echo.
BTW, I remembered interesting fact. On March 15 I tested new video calling with Signal 3.31.4 on both ends between my Moto X2 (XT1095, custom 7.1.1) and Galaxy S5 (SM-G900F, stock 6.0.1). Except #6356 it was perfect, no echo at all on both ends. Next time I called on March 29, with Signal 4.1.0 on both ends (in which S5 was blacklisted) and other side clearly heard the echo from me in that time. Since then I have always been complaining about the echo. How could this be?
@lantsem if the person hearing the echo is the one using the Galaxy S5, then it's unrelated to the S5 being blacklisted
@haffenloher I am fully aware of this and talking about different things:
@lantsem I guess you had the X2's speaker enabled in all cases? It's possible that the (hardware) AEC performance differs depending on the room, where the phone lies, the speaker volume etc.
We tested video with 3.31.4, so speaker was enabled. Now I'm getting complaints even without speaker and I hear an echo without speaker too (from Wileyfox Swift as I wrote earlier). Room condition is the same, phone software wasn't changed, volume too. Strangely.
Now I'm getting complaints even without speaker
That's an issue I've seen exclusively with CM / LineageOS users so far. Looks like there's something seriously wrong on their end π
Maybe it's something CAF related? I have an old Galaxy Nexus with LOS13, that seems to works without echo (it has some different sound artifact, not so important), but I'm not sure that there is any hardware AEC in it at all.
Tested integrated SIP calls with S5, same conditions. No problems as always.
- Disable hardware AEC for everyone. Really simple and completely eliminates problem for all cases.
I'm leaning towards this, but it might be an overstatement to say that it will completely eliminate the problem. There could be a class of devices where hardware AEC works but software AEC doesn't for some reason, we don't know.
Yes, I had to insert 'maybe' into this sentence. That's why I suggested a 3rd choise with hidden option to enable hardware AEC to overcome potentional problems and report back to developers. This option for toggle hardware/software mode can also be used for quick testing of different modes in the same conditions, so it could give back much more detailed feedback from advanced users.
But how bad it could be with global software AEC rollout? If you look at current blacklist and take into account the popularity of listed devices, hardware AEC issue already hit quite hard. Even S5, S7 and Google's own Nexus/Pixel (i.e. phones with good and long software support) do not garantee the absence of problems. And it could be much worse on many other cheaper phones, about which we don't know. Please correct me, if I wrong, did redphone code use software AEC? Did you have a lot of reports about the AEC in that time? Personally I had no problems with redphone or SIP AOSP client (that seems to use software AEC). So the question is only about quality of software AEC in webrtc, am I right?
From the side it seems that the amount of phones, which could have problems with webrtc's software AEC, can be significantly lower than in the case of hardware AEC. Of course I can be wrong, and only real statistics will show.
Can someone do a pr to add Xperia Z to AEC blacklist.
ro.product.model : C6603
@moxie0 my impression is that the hardware AEC is very often broken, even on high end devices with stock system images. Disabling the hardware AEC by default seems the most reasonable thing to do. If there are devices where software AEC doesn't work but hardware AEC does, they could be whitelisted, inverting the current logic.
I've switched to a whitelist, so let's start this process over again. =) Any devices we know do work?
I haven't had any problems with echos on my Moto G 2014 (Titan) on LineageOS 14.1, I can tell that much. Same for my partner's Moto G (Falcon) (on LineageOS 14.1 as well).
Any devices we know do work?
Wouldn't the appropriate question be...
Any devices we know that don't work with software AEC?
@RiseT My intuition is that software AEC will always reduce performance in some way (battery life at the least), so we should try to use hardware AEC whenever we can.
I didn't had any problems with my HTC 10 (LineageOS 14.1):
[ro.product.model]: [HTC 10]
Sony Xperia Z1 Compact (D5503, stock Android 4.4.4) and Z3 Compact (D5803, stock Android 6.0.1) appear to work in the current hardware AEC setup.
It looks like a lot of work keeping track of all the different combinations of device and OS version, though. Especially when just one (future) minor OS update on a device can break a previously working (and potentially whitelisted) hardware AEC. Just a thought.
Another thought:
How are users supposed to test hardware AEC for device/OS version combinations in order to potentially get them whitelisted, when starting with Signal 4.3.0, software AEC is used when a device/OS combination is not on the whitelist already...? Thats a catch-22.
Another thought on this is that sometimes a junky driver can make it echo until you reboot and then it's fine for awhile, emphasizing RiseT's point of Phone+OS unique identifier for AEC style
Just let users enable hardware AEC in the settings for better performance (with a warning that this causes echo on some devices). This option will be disabled by default.
If they experience echo they will know the culprit and can turn it off again.
Just let users enable hardware AEC in the settings for better performance (with a warning that this causes echo on some devices). This option will be disabled by default.
That's the only solution I can think of that doesn't require constant pampering.
I've switched to a whitelist, so let's start this process over again. =) Any devices we know do work?
Two more models which worked fine before the switch to a whitelist: "D5803" (Sony Xperia Z3 Compact) and "FP1" (Fairphone 1).
Two more models which worked fine before the switch to a whitelist: "D5803" (Sony Xperia Z3 Compact) and "FP1" (Fairphone 1).
The same applies to: "SM-A500FU" (Samsung Galaxy A5 2015) and "XT1092" (Motorola Moto X 2014).
Full device names (from debug log) are: "samsung SM-A500FU (a5ultexx)" and "motorola XT1092 (victara_retde)".
We had many video calls with these devices and the audio quality was superb (indoor with WiFi and outdoor (only voice) with 4G). After the update to 4.4, we now have inferior quality (abrupt changes in volume etc.), even in cases, where there are absolutely no surrounding noises (e.g. both are at home).
If you need any more information (e.g. a debug log) or if I should open a separate issue, just let me know!
I also think with 7.1.2 Nexus 6P echo got fixed
Wanted to report back in reference to my comment 1 month ago that bacon is now fixed either due to the whitelist or 7.1.2 (lineage). I do not know which but finally the non-proximity related screeching noises are gone and I can go back to using calling again.
I also think with 7.1.2 Nexus 6P echo got fixed
@sigenc what does that mean? Did you test this with a version of Signal older than v4.3.0 (i.e. without 51f27631)?
Moto G (4) (athene_f)
has worked well all the time.
This is what signal's debug log reports under Device :
Is that what's needed?
For a better test: Is it possible to add AEC
as a setting in signal?
I have two FP2 (Fairphone 2) on Android 5.1 with signal 4.5.3.
The audio quality depends on call to call excellent to inferior.
I'm not sure if it depends on the network quality.
If you need more info, just let me know.
Just thought i'd drop a comment here because i'm facing a similar issue in a closed source video chat application i'm working on.
In our app - if the call is between just 2 people we use webRTC. If there are more than 2 participants then we use our own A/V code and route all of the data through a server. When using our own code (which makes use of the Java layer audio classes AudioTrack and AudioRecord) we find that the hardware Echo cancellation works fine on all the devices we can get our hands on. But when the call utilises webRTC, certain devices hardware AEC fails completely despite working fine with the Java audio system.
I have not yet dug too far into the webRTC codebase but it seems that there is something about the way webRTC interfaces with the devices' sound system that causes the hardware AEC to fail.
I notice you guys went down the route of whitelisting which is something i'm very eager to avoid.
I'll keep you posted if I manage to figure out exactly what webRTC is doing to cause problems with hardware AEC.
@deano2390 FWIW the webrtc folks explicitly recommend disabling OpenSLES and always using the AudioTrack/AudioRecord interface (WebRtcAudioManager.setBlacklistDeviceForOpenSLESUsage(true)
).
The big remaining mystery to me now is how apps like Duo/Hangouts manage to use webrtc and actually ring correctly. My calls to AudioManager to setMode() for ringtone always get clobbered by webrtc.
In the 4.7.1 beta, I've switched back to a blacklist. Here is my set of assumptions:
1) Hardware AEC seems to function properly when using the Java AudioTrack/AudioRecord interface (we think!). It seems to function poorly when using the OpenSL ES interface (causing this issue).
2) WebRTC AEC seems to function properly when using the OpenSL ES interface, but poorly when using the AudioTrack/AudioRecord interface. This causes issue #6737.
3) Many devices seem to "drop" audio after some period of time when using the OpenSL ES interface. This causes issue #6432.
As a result, there are three issues that are somewhat in tension with each-other: this issue, #6737, and #6432.
My current thinking is that we disable OpenSL ES by default to address #6432, that we leave hardware AEC on to address #6737, and that hopefully there aren't regressions with echo in this issue because we're using the AudioTrack/AudioRecord interface instead of OpenSL ES.
Please let me know if 4.7.1 causes regressions for anyone here (remember it would have to be the person on the other end of the call running 4.7.1 with a regression that would cause you to hear echo).
I'm running 4.7.3 on Fairphone 2 (Android 6.0.1) and just got the feedback from a Signal-iOS user that she can hear her own echo.
Moto X (2014) running LineageOS 14.1 got echo again with 4.7.4.
@lantsem What does that mean? _You're_ hearing echo when you're talking to _someone else_ who has a Moto X (2014) running LineageOS 14.1 and Signal 4.7.4?
edit: sorry, just scrolled back through this thread, looks like you're aware of this distinction, so the answer is probably yes :)
Moto X (2014) running LineageOS 14.1 got echo again with 4.7.4.
I'm running 4.7.4 with Android 6.0 on a Moto X 2014 (XT1092), too (since the beta has been available). The other side is usually a Galaxy A5 2015 (SM-A500FU) and we do not have any echo or other calling issues, even outside when I'm using my Moto X and it's quite windy.
@haffenloher Yes, from several phones that I tested with 4.7.4 only Moto X 2014 running LOS 14.1 shows an issue. But the impression was created that the echo became less noticeable for normal talk (not on speaker).
@minnmann My second Moto X 2014 with stock 6.0 didn't have echo with hardware AEC even with OpenSL ES. I wrote about it earlier.
Moto G5 with stock 7.0 and 4.7.4 also has an echo with speaker mode.
Was having echo issues with the Moto G5. Compiled v4.7.4 with add("Moto G5"); in the blacklist.
No more tortuous echo for the people that listen to me.
src/org/thoughtcrime/securesms/ApplicationContext.java
private void initializeWebRtc() {
Set
add("Pixel");
add("Pixel XL");
add("Moto G5");
......
Echo is gone. Works well now. Could you add the Moto G5. It has a very broken AEC
@adlererik with the Moto G5's stock rom or with a custom OS?
@adlererik What happens when you also add Moto G5 to the opensles whitelist?
@moxie0 Sorry for the late response. Have tested two Moto G5 phones with opensles whitelisted
Signal v4.9.9 and v4.10.10 tested.
Phone 1: Moto G5 100% stock unrooted
Phone 2: Moto G5 LineageOS
src/org/thoughtcrime/securesms/ApplicationContext.java
Set<String> HARDWARE_AEC_BLACKLIST = new HashSet<String>() {{
add("Pixel");
add("Pixel XL");
add("Moto G5");
Set<String> OPEN_SL_ES_WHITELIST = new HashSet<String>() {{
add("Pixel");
add("Pixel XL");
add("Moto G5");
Test conditions:
Both Moto G5s called each other. Both Moto G5s called an iPhone 6.
Results:
Additionally whitelisting opensles ever so slightly might have improved the sound on the stock G5 during phone conversations. This is subjective. No improvement was noted with LineageOS.
Conclusion:
a) Using AEC_BLACKLIST is a must have as AEC is broken on the G5. OPEN_SL_ES_WHITELIST is probably redundant.
b) Lenovo Moto hw is junk and their code is profoundly buggy.
My Samsung GT-I9192 Galaxy S4 Mini Duos (serranodsxx) with Signal 4.11.5 on Android 7.1.2 (LineageOS 14.1-20170615-nightly-serranodsdd) is causing echo for other end (Samsung Note 3, I think).
This echo gets worse when a headphone is used on my end. This means that the echo does not originate from my microphone picking up the other end's audio, but must happen inside the system/software stack. (Perhaps echo cancellation is effectively adding the echo?)
The other end is my mother, who I'm trying to convince to continue using Signal, so this is important. ;-)
I don't think I ever encountered a Lineage OS phone which didn't produce echo. If it's their bug, putting every Lineage user's phone on Signal's hardware blacklist would be counterproductive.
@haffenloher I have made Signal calls regularly on a Moto G, Moto G2, and Moto G4 Play, all on LineageOS, and never experienced echo issues.
@AlfonsoMuskedunder To be sure: you do mean that no echo was produced at the other end, no? In any case, it may still be a LineageOS bug, but just not for all devices.
@haffenloher
Searching for βechoβ in the LineagOS bug tracker, I find the following reports (all reported for specific devices) that may be relevant:
Most promising:
Phone echo β Little information in bug report, but a linked patch mentions something interesting about the second microphone:
default backends of IN_HDMI_MIC and IN_HANDSET_MIC by qualcomm are defined for single mic devices which breaks secondary mic for noise cancellation on dual mic devices like onyx while recording audio on apps like whatsapp, telegram etc.
May be useful:
In any case, it may be useful to get a LineageOS developer to chip in here. I guess the best way is via a bug report in their tracker referencing this issue. I could do that, but I guess a Signal contributor would be better suited.
Also, to not let this idea fall by the wayside: Is disabling echo cancellation when using a headphone a possibility?
@haffenloher Tested voice calls with Moto G and Galaxy S5, both on latest LineageOS 14.1 builds. They didn't have echo issue.
I have to report a massive echo during video calls with a Sony Xperia Z5 compact.
Model: E5823
Android-Version: 7.1.1
Signal-Version: 4.13.6
The owner is willing to update to a test-build or join the Beta-club.
@McLoo Do you still use that model and people you talk to can confirm the problem?
I have an FP2 (Open OS v17.11.2) with Signal v4.13.6 installed via YalpStore. People I call experience an echo of themselves at their end unless I use headphones. This has been the case since August (following stable update releases).
If you read this thread from the beginning you will find out that this issue was originally about the FP2. Unfortunately this seems to be an issue with the hardware AEC of the Fairphone ROM. Additionally working around this by blacklisting hw AEC seems to make the phone crash. So if I got it correct Fairphone should either fix their hardware AEC or the crash when it is blacklisted.
I experience an echo with someone who is using the following:
Device : OnePlus ONE E1003 (OnePlus)
Android : 5.1.1 (4, ONE E1003_14_160420)
Memory : 38M (33.31% free, 512M max)
Memclass: 192
OS Host : ubuntu-56
App : Signal 4.14.10
Similarly to @ghost, I have a Fairphone 2 running Fairphone Open OS v17.12.1 (based on Android 6.0.1) and Signal v4.14.10.
The people I call hear an echo of themselves as long as I don't use headphones, but I don't hear an echo of myself.
So I tried adding the Fairphone 2 to Signal's hardware AEC blacklist as follows, in src/org/thoughtcrime/securesms/ApplicationContext.java
:
private void initializeWebRtc() {
try {
Set<String> HARDWARE_AEC_BLACKLIST = new HashSet<String>() {{
add("Pixel");
add("Pixel XL");
add("Moto G5");
add("FP2");
}};
I only tried this change with a single call for now, but the other party's echo was almost gone (i.e. it was still there, but its volume was so low it wasn't really bothersome) and my FP2 did not crash.
The only downside is that I could hear a low-volume echo of myself, just like the other party, during that call.
Anyway, the situation is still better than with Signal 4.14.10 vanilla.
After updating to 4.15 (beta), the following combination leads to an echo when using video chat:
Me: "motorola Moto G (5) (cedric)" (Moto G5), Signal 4.15 (beta)
Other person: "SM-A500FU" (Samsung Galaxy A5 2015), Signal 4.14 as well as Signal 4.15 (beta)
The echo occurs only on the other phone (Samsung A5). After 5-10 minutes the echo vanishes; only then and now some minor noise can be heard.
I really appreciate the effort and all the new features coming to signal last year!
However, I can support @Le1b1 on echoing problems with the Sony Xperia Z5 Compact
. I can hear my counterpart clearly, but they experience bad quality since the change to webRTC. This makes my live bringing friends and family to Signal quite hard. It would be very interesting to see what happens by adding all the Xperia Z5 models to the blacklist, as I only use signal for messaging these days.
I also support a settings feature to Enable/Disable AEC. I see the point that it is not easy understandable for non-techies that the one with the clear audio has to disable it. So what about a dialog after the call which asks something like, "did your counterpart complained about hearing himself during the call? (yes/no)" when they click yes, It will disable it, so there is no technical understanding needed.
Maybe this dialog has to be shown only once, or once after each update, to not annoy the ones that experience no problems. Also, on a yes, I would kindly ask if it would be possible to send the logs - by clicking a nice button in friendly letters - which would bring even more light to the problem.
Name: Sony Xperia Z5 Compact
Model: E5803
Android-Version: 7.1.1
Signal-Version: 4.15.5 / Happens also on all minor versions since webRTC
My communication partners also hear them self, if I use headphones or speaker.
Phone: Honor 5X (KIW-L21)
OS: LineageOS 14.1 (Android 7.1.2)
Signal: 4.15.5
I understand that you (the developers) would prefer a real solution instead of a workaround. But given that this issue with high impact has not been fixed for a while now, it seems to me that a workaround (setting, disabling AEC when using headphones,β¦) would be the right thing to do for now.
I have been driven back to Skype for communicating with people I'd managed to convince to install Signal. Before the whitelist-to-blacklist change, things worked well for me. I'd like to avoid using Skype for all kinds of reasons, as you probably understand. So, please do something about this.
I've had to switch to Wire's videochat, which isn't as good. Signal's current blacklist approach is not sustainable.
There's a strong echo with Motorola Moto G 3rd generation (XT1540), stock unrooted Android 6.0, current Signal version 4.15.5 .
I have a oneplus 2 running lineage OS 14.1 and every time I call my friend on speakerphone he (has a iPhone 5 or something) complains how he can hear himself louder than me.
This means I can't use speaker phone.
Signal version: 4.15.5 ( had this issues a few versions back too... Since I started using Signal which was 5 months ago)
The Moto G4, running LineageOS 14.1, also causes the person on the other end to hear an echo when speaker is enabled.
[ro.product.device]: [athene]
[ro.product.manufacturer]: [Motorola]
[ro.product.model]: [Moto G4]
[ro.product.name]: [lineage_athene]
GitHub Issue Cleanup:
See #7598 for more information.
Most helpful comment
Just let users enable hardware AEC in the settings for better performance (with a warning that this causes echo on some devices). This option will be disabled by default.
If they experience echo they will know the culprit and can turn it off again.