All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=892534

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=d74881d19221d0b6b55e00071cd17aeacdd0e6eaea8a87c6b3f568eb454fea5c


Bot(s) for this bug's original alert(s):

chromium-webrtc-rel-7
chromium-webrtc-rel-mac
chromium-webrtc-rel-win10
chromium-webrtc-rel-win8

It looks like the number of opus packets/second has increased recently, but I can't find a likely CL to blame. Could you have a look at this Minyue?

This happened recently on Linux as well. Is related to changing field trials so that APM in Audio Service is being run on the bots.

I've run it locally and get the following results (sans video stats):

APM in Renderer:
RESULT audio_misc_recvonly_with_opus_dtx: packets_lost= [0,0,0,0,0,0,0,0,0,0] frames
RESULT audio_rates_recvonly_with_opus_dtx: goog_expand_rate= [0.0611572265625,0,0,0,0,0,0,0,0,0] %
RESULT audio_rates_recvonly_with_opus_dtx: goog_secondary_decoded_rate= [0,0,0,0,0,0,0,0,0,0] %
RESULT audio_rates_recvonly_with_opus_dtx: goog_speech_expand_rate= [0.0313720703125,0,0,0,0,0,0,0,0,0] %
RESULT audio_rx_recvonly_with_opus_dtx: goog_jitter_recv= [3,3,3,3,3,3,2,2,2,2] ms
RESULT audio_tx_sendonly_with_opus_dtx: goog_jitter_recv= [3,3,3,3,3,3,2,2,2,2] ms
RESULT audio_tx_sendonly_with_opus_dtx: goog_rtt= [4,4,4,4,4,4,1,1,1,1] ms
RESULT audio_tx_sendonly_with_opus_dtx: packets_sent_per_second= [0,40,43,42,41,42,41,42,42,40] packets
RESULT bwe_stats_recvonly_with_opus_dtx: actual_enc_bitrate= [0,0,0,0,0,0,0,0,0,0] bit/s
RESULT bwe_stats_recvonly_with_opus_dtx: available_recv_bw= [0,0,0,0,0,0,0,0,0,0] bit/s
RESULT bwe_stats_recvonly_with_opus_dtx: available_send_bw= [300000,300000,300000,300000,300000,300000,300000,300000,300000,300000] bit/s
RESULT bwe_stats_recvonly_with_opus_dtx: target_enc_bitrate= [0,0,0,0,0,0,0,0,0,0] bit/s
RESULT bwe_stats_recvonly_with_opus_dtx: transmit_bitrate= [0,0,0,0,0,0,0,0,0,0] bit/s
RESULT bwe_stats_sendonly_with_opus_dtx: actual_enc_bitrate= [1450016,1714640,1697056,1685296,1680616,1712376,1656440,1680680,1638800,1655352] bit/s
RESULT bwe_stats_sendonly_with_opus_dtx: available_recv_bw= [0,0,0,0,0,0,0,0,0,0] bit/s
RESULT bwe_stats_sendonly_with_opus_dtx: available_send_bw= [3576842,3576842,3576842,3576842,3576842,3576842,3576842,3576842,3576842,3576842] bit/s
RESULT bwe_stats_sendonly_with_opus_dtx: target_enc_bitrate= [1700000,1700000,1700000,1700000,1700000,1700000,1700000,1700000,1700000,1700000] bit/s
RESULT bwe_stats_sendonly_with_opus_dtx: transmit_bitrate= [1510104,1792408,1783016,1776680,1765672,1798328,1734296,1767712,1714744,1738624] bit/s

APM in Audio Service:
RESULT audio_misc_recvonly_with_opus_dtx: packets_lost= [0,0,0,0,0,0,0,0,0,0] frames
RESULT audio_rates_recvonly_with_opus_dtx: goog_expand_rate= [0.04669189453125,0,0,0,0,0,0,0,0,0] %
RESULT audio_rates_recvonly_with_opus_dtx: goog_secondary_decoded_rate= [0,0,0,0,0,0,0,0,0,0] %
RESULT audio_rates_recvonly_with_opus_dtx: goog_speech_expand_rate= [0.01385498046875,0,0,0,0,0,0,0,0,0] %
RESULT audio_rx_recvonly_with_opus_dtx: goog_jitter_recv= [2,2,2,2,2,2,2,1,1,1] ms
RESULT audio_tx_sendonly_with_opus_dtx: goog_jitter_recv= [2,2,2,2,2,2,2,1,1,1] ms
RESULT audio_tx_sendonly_with_opus_dtx: goog_rtt= [3,3,5,5,5,5,5,4,4,4] ms
RESULT audio_tx_sendonly_with_opus_dtx: packets_sent_per_second= [0,32,48,49,51,50,49,49,51,50] packets
RESULT bwe_stats_recvonly_with_opus_dtx: actual_enc_bitrate= [0,0,0,0,0,0,0,0,0,0] bit/s
RESULT bwe_stats_recvonly_with_opus_dtx: available_recv_bw= [0,0,0,0,0,0,0,0,0,0] bit/s
RESULT bwe_stats_recvonly_with_opus_dtx: available_send_bw= [300000,300000,300000,300000,300000,300000,300000,300000,300000,300000] bit/s
RESULT bwe_stats_recvonly_with_opus_dtx: target_enc_bitrate= [0,0,0,0,0,0,0,0,0,0] bit/s
RESULT bwe_stats_recvonly_with_opus_dtx: transmit_bitrate= [0,0,0,0,0,0,0,0,0,0] bit/s
RESULT bwe_stats_sendonly_with_opus_dtx: actual_enc_bitrate= [1708584,1664240,1690920,1681032,1726456,1657968,1745000,1688304,1720584,1646192] bit/s
RESULT bwe_stats_sendonly_with_opus_dtx: available_recv_bw= [0,0,0,0,0,0,0,0,0,0] bit/s
RESULT bwe_stats_sendonly_with_opus_dtx: available_send_bw= [4914000,4914000,4914000,4914000,4914000,4914000,4914000,4914000,4914000,4914000] bit/s
RESULT bwe_stats_sendonly_with_opus_dtx: target_enc_bitrate= [1700000,1700000,1700000,1700000,1700000,1700000,1700000,1700000,1700000,1700000] bit/s
RESULT bwe_stats_sendonly_with_opus_dtx: transmit_bitrate= [1782536,1645384,1729520,1715208,1818880,1635800,1790424,1721832,1759016,1737144] bit/s

It's not clear to me that the bitrate has changed noticeably, but the number of packets is now around 50 rather than around 40.
Having the APM running in the audio service does not affect encoding directly, as that is still run in the renderer process.
I do believe the APM no longer downmixes when running in the audio service - it used to always have a mono output format, now it's whatever the number of channels are chosen for input.

Oddly enough, it looks like we've an higher available send bandwidth, though perhaps that changes from run to run?

Do these stats tell any of you something?  

+hlundin@

Hi, could you PTAL? Trying to figure out if this change is good, bad or neutral. It looks like there are more packets, but the bit rate is about the same. Any ideas? Could DTX become disabled if Opus is fed with stereo audio?

The number of packets that Opus sends per second should not change with the available bitrate in these tests. I believe they are wired up to use a fixed target bitrate and frame size. Thus, any change in packet frequency must come from a change in the audio input, so that the relation between speech and DTX packet changes.

Can you reproduce this locally? If so, we can check the input and config to Opus.

I can. I'll add some logging of those things and see what I come up with. IIRC, the input is a repeatedly beeping tone generator, so the actual audio between runs should be comparable if not identical.