1053112 - [Loop] During a video call the sound is a bit choppy and metallic/robotic

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Loop, defect)

Description

[mbarone]

Attachment: log_caller_FireE.txt

Device: Flame (Incoming video call), Fire E (Outgoing call)

Loop Id: 609ec57

After few seconds of video call the audio is a bit choppy and metallic. The video starts to freeze for few seconds and the delay increase.

Attached the logcat of both devices

Comment 1

[mbarone]

Attachment: log_receiver_Flame.txt

Comment 2

[Nils Ohlmeier [:drno]]

Does this happen with Video + Audio calls only, or does the same problem exist for Audio only calls as well?

Comment 3

[mbarone]

With the today build the only problem with the audio call was the delay, but the quality of the sound was good

Loop Id: 609ec57
Gecko-7f737a2
Gaia-6155d46

Maybe the volume of the audio is still a little bit low.

Comment 4

[Maire Reavy [:mreavy]]

When you do your video calls, are you using VP8 or H.264?  If you're using VP8, can you try reducing your video resolution and report back what impact that has?   Are you using JB or have you upgraded to KK?   Thanks

Comment 5

[mbarone]

Our builds use H.264. Still I couldn't test with JB.

Comment 6

[Maire Reavy [:mreavy]]

(In reply to mbarone from comment #5)
> Our builds use H.264. Still I couldn't test with JB.

So you have upgraded to Kitkat?   When did you upgrade to Kitkat?

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

It would help to know the build ID's/commit hashes for the base build and the gaia and gecko you're using.  (basically we want to ensure we're looking at the same builds you are)

Things to try, generally in-order:
top:
   adb shell top | tee /tmp/top_output
in the middle of a call showing the problem.  Also
   adb shell top -h (or -H) | tee /tmp/top_output (gives per-thread data)

Try a call at http://talky.io/tef and see if you have similar problems.

vp8: add:
   user_pref("media.peerconnection.video.h264_enabled", false);
to /data/b2g/mozilla/<profile>/all.js

You can verify H.264 vs VP8 is the default by using http://mozilla.github.com/webrtc-landing/pc_test.html.  Select "Require H.264" and "One-way call", then Start.  See if the call connects, and if it doesn't, scroll down and see if it says something like H.264 not found.  (And find and paste the "m=video NNNNN RTP/SAVPF XXX YYY" line here - if it just has "120", it's vp8 only; if it has 126 it is H.264 (the initial offer should have both)

(use "adb pull <remote file> <local path>" to grab a copy, then "adb push <local file> <remote file or path>")

lower resolution:
   user_pref("media.navigator.video.default_width", 160);
   user_pref("media.navigator.video.default_height", 120);

Comment 8

[mbarone]

Device: Flame
Build: Gecko:db9c374 - Gaia:8b1b64c
Loop version: 609ec57

Test1
Calls between Fire E and Flame in different wifi network - adb shell top | tee top_output.
Logs of Flame device (Incoming call). Logs of Fire E (Outgoing call). Call between two FxA

Result: After 60 seconds the video froze and the audio was chopped.

Attached the logs
-----------------------
Test2
Same conditions and devices that Test 1. adb shell top -t | tee top_output
After 40 seconds video froze and audio was chopped and robotic
Attached the logs
------------

Try a call at http://talky.io/tef and see if you have similar problems.

No sound is detected error. 
I can't use the micro. This web only ask me the permission of camera.

------------------
using http://mozilla.github.com/webrtc-landing/pc_test.html
Results
m=audio 39549 RTP/SAVPF 109 0 8 101
m=video 41597 RTP/SAVPF 126 120
Also attached the rest of the data

------------
I couldn't find all.js, I have changed the pref.js file

massimo$ adb pull /data/b2g/mozilla/7fv8hdex.default/all.js .
remote object '/data/b2g/mozilla/7fv8hdex.default/all.js' does not exist

We have the same results, audio choppy and video freeze after 1 minute (aprox) using both configuration 160 and 120.

Comment 9

[mbarone]

Attachment: test 1.zip

Comment 10

[mbarone]

Attachment: test 2.zip

Comment 11

[mbarone]

Attachment: browser data.zip

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

A couple of things to note:

The Fire/E is showing >10% in the qcamera driver; flame is ~1%.  We've seen this on Flames when using the back camera, but not with the front.  This appears to be a HW driver issue which depends on what sort of camera is specified and the driver code that runs it.  Nexus 4's show ~1% front or rear.

on both, I'm seeing ~93-98% CPU use, which is higher than I've ever seen.  System cpu use is running 27-35%(!)

Part of the difference is I'm seeing the Loop app thread use 10% all by itself; my measurements of Talky.io for example were 1-3% in-call for the Browser.  Add that to the qcamera (on Fire/E) and you're talking 20% or so.

Do you know what frame rate the camera is running?

It appears these are using H.264, but without the ADSP fixes from QC.

Comment 13

[Tony Chung [:tchung]]

Jayme, Peter, can you guys investigate this against the Flame?  You'll need to grab the latest build and flash a KK build.   Please report if you can reproduce this with the KK Flame image (v162-3) and run against 2.0.

Comment 14

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I was unable to reproduce this issue on the latest Flame 2.0 running the v165 KK base for both devices.  The call sound never became choppy or metalic after 2 minutes.
0/5 attempts reproduced the issue.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140815143240
Gaia: d889984833025f208cfd3f3c2c37c87940a529dc
Gecko: 6329352ca531b977979451e77e5862af485388b2
Version: 32.0 (2.0) 
Firmware Version: v165
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Loop Version: 32219a2

Comment 15

[Maria Angeles Oteo (:oteo)]

Based on comment 14, let's close this bug as fixed, adding ni to massimo so he can check on his side when we have access to KK builds.