New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 774333 link

Starred by 1 user
Status: Untriaged
Owner: ----
Cc:
mbonadei@chromium.org
ossu@chromium.org
hlundin@chromium.org
█ choonc@google.com
█ phoglund@chromium.org
█ zhihuang@chromium.org
█ lliuu@chromium.org
█ skvlad@chromium.org
harpreet@chromium.org
█ katierh@chromium.org
EstimatedDays: ----
NextAction: 2019-07-09
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Continuously error log from webrtc/modules/audio_coding/acm2/audio_coding_module.cc

Project Member Reported by mzhuo@chromium.org, Oct 13 2017 
Chrome Version: 
        Guado running meeting mode 
	ChromeOS: 9765.84.0	
        Chrome:   61.0.3163.123	

What steps will reproduce the problem?
(1) join meeting

What is the expected result?
No error

What happens instead?
/var/log/chrome/chrome:
[1:215:1012/183835.250127:ERROR:neteq_impl.cc(1154)] Packet missing where it shouldn't.
[1:215:1012/183835.250286:ERROR:acm_receiver.cc(128)] AcmReceiver::GetAudio - NetEq Failed.
[1:215:1012/183835.250395:ERROR:audio_coding_module.cc(1115)] PlayoutData failed, RecOut Failed
[1:215:1012/183835.250554:WARNING:audio_mixer_impl.cc(199)] GetAudioFromSources: failed to GetAudioFrameWithInfo() from source
debug-logs_20171012-183935.tgz
2.1 MB Download

Comment 1 by mzhuo@chromium.org, Oct 13 2017 

The  4 lines of log happens to all Guado setup. from  webrtc-internal seems the other party is able to received audio stream. 
This log is new for ChromeOS: 9765.84.0	and Chrome:   61.0.3163.123. With previous R61 image did not see these error log.
Screen Shot 2017-10-12 at 6.25.53 PM.png
587 KB View Download
Screen Shot 2017-10-12 at 6.26.09 PM.png
613 KB View Download

Comment 2 by mzhuo@chromium.org, Oct 13 2017

Cc: -honghaiz@chromium.org -mbonadei@chromium.org choonc@google.com katierh@chromium.org

Comment 3 by mzhuo@chromium.org, Oct 13 2017

Cc: -ossu@chromium.org harpreet@chromium.org

Comment 4 by mzhuo@chromium.org, Oct 13 2017

Cc: honghaiz@chromium.org mbonadei@chromium.org

Comment 5 by mzhuo@chromium.org, Oct 13 2017

Cc: ossu@chromium.org

Comment 6 by mzhuo@chromium.org, Oct 13 2017

Cc: -honghaiz@chromium.org phoglund@chromium.org

Comment 7 by hlundin@chromium.org, Oct 16 2017 

The NetEq error clearly shows that some anomaly has happened. I'm going to try to figure out what the conditions may be.

In the meantime, there are a lot of SSRC errors. E.g.,
"The SSRC X is not associated with a receiving track"
"receive_rtp_config_ lookup failed for ssrc Y"

What's up with that?

Comment 8 by hlundin@chromium.org, Oct 16 2017 

Also, what Chrome revision was the previous M61 image that was supposed to work?

Does this repro on other platforms than Guado?

Comment 9 by hlundin@chromium.org, Oct 16 2017

Cc: hlundin@chromium.org

Comment 10 by mzhuo@chromium.org, Oct 16 2017 

for #7 I have seen "The SSRC X is not associated with a receiving track"
"receive_rtp_config_ lookup failed for ssrc Y" since I started working on this project. 

for #8 I did not test other platform than guado. 
Before 9765.84.0  I tried ChromeOS: 	9765.82.0 and Chrome	61.0.3163.121, did not see this issue.

Comment 11 by hlundin@chromium.org, Oct 17 2017 

OK, thanks.

If you want me to investigate any more from the NetEq point-of-view, I would either need an RtcEventLog recording (from the receiving side) when this happens, or a detailed description how I can reproduce this on regular desktop Chrome.

An RtcEventLog is created by opening up chrome://webrtc-internals, expand the Create Dump section, and check "Enable diagnostic packet and event recording".

Comment 12 by benhenry@google.com, Jan 10

Labels: Pri-3
NextAction: 2019-07-09
Downgrading P2s that haven't been modified in more than 6 months, which have no component or owner.
►

Sign in to add a comment