WebRTC 一对一语音通话中音频端到端分段延迟分析

最新推荐文章于 2023-09-19 15:20:13 发布
最新推荐文章于 2023-09-19 15:20:13 发布
阅读量2.1k 收藏 13
点赞数 6
分类专栏： C/C++ 开发 实时音视频开发 文章标签： 音视频 webrtc 语音识别
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/tq08g2z/article/details/126674812
版权

WebRTC 一对一语音通话中的音频端到端延迟指从一个音频信号被发送端采集，到同一个信号被接收端播放出来这整个过程的时间。音频端到端延迟由多个阶段组成。音频端到端处理的冲采样、混音、回声和降噪等操作会使音频数据在数值上变得面目全非，变得难以比较。真正的音频端到端延迟一般使用专业的声卡设备配上专门的音频处理软件来测，这种测试在线上环境中是难以实现的。音频端到端分段延迟常常也能在很大程度上反应音频端到端延迟，分段延迟的分析甚至可以帮我找到造成延迟的瓶颈所在。

WebRTC 一对一语音通话中音频处理的主要过程

WebRTC 一对一语音通话中音频的处理主要经过了如下的过程：

  1. 音频采集；
  2. 音频数据处理，也称为音频的前处理，主要包括回声消除、降噪和自动增益控制等；
  3. 音频编码；
  4. 编码音频包的发送；
  5. 编码音频包在网络中的传输；
  6. 从网络中接收音频包；
  7. 音频包在缓冲区中等待被解码处理；
  8. 音频解码及播放。

这里分析这其中每个阶段的延迟。

音频采集延迟

当启动设备的音频采集时，开发者可能可以对系统的音频采集数据缓冲区大小做一些配置，也可能系统有一些自动的配置。当采集数据缓冲区满时，应用层代码可以通过系统的回调，或者主动调用获取音频采集数据的接口获取采集的音频数据。

在 WebRTC 中，通过 webrtc::AudioDeviceModule 与音频设备交互，这包括与音频采集设备的交互。WebRTC 为不同的操作系统平台，甚至是同一操作系统平台的不同音频接口提供不同的 webrtc::AudioDeviceModule 的具体实现。webrtc::AudioDeviceModule 屏蔽不同操作系统平台及各种音频接口获取采集的音频数据的方式的差异，用一种统一的方式，也就是回调接口 webrtc::AudioTransport，将采集的音频数据送出去。webrtc::AudioDeviceModule 每次通过 webrtc::AudioTransport 送出去 10 ms 的音频采集数据，比如，如果音频采集设备的采样率是 48 kHz，则每次送出每通道 480 个采样点的音频数据，进一步如果音频采集设备的通道数是 1，则每次共送出 480 个采样点的数据，而如果音频采集设备的通道数是 2，则每次共送出 2 * 480 = 960 个采样点的数据。

以 Mac 平台为例，webrtc::AudioDeviceModule 将数据送到 webrtc::AudioTransport 的调用过程大体如下：

  * frame #0: webrtc::AudioTransportImpl::RecordedDataIsAvailable(audio_data=0x0000000106f450d0, number_of_frames=480, bytes_per_sample=2, number_of_channels=1, sample_rate=48000, audio_delay_milliseconds=2147981, (null)=0, (null)=0, key_pressed=false, (null)=0x000070000d2366ac) at audio_transport_impl.cc:118:3
    frame #1: webrtc::AudioDeviceBuffer::DeliverRecordedData() at audio_device_buffer.cc:271:38
    frame #2: webrtc::AudioDeviceMac::CaptureWorkerThread() at audio_device_mac.cc:2495:22
    frame #3: webrtc::AudioDeviceMac::StartRecording()::$_1::operator()() const at audio_device_mac.cc:1314:16

音频采集在 WebRTC 一对一语音通话中造成延迟，主要在于音频采集数据缓冲区大小的设置，和 10 ms 数据帧格式的对齐。不难理解，采集数据缓冲区越大，填满缓冲区所需的数据量就越多，所需时间越长，整体消耗的系统 CPU 资源更少，但音频采集延迟更大；而采集数据缓冲区越小，则填满缓冲区所需数据量越少，所需时间越短，整体消耗的系统 CPU 资源更多，但采集延迟更小。采集数据缓冲区大小决定通过系统接口获取音频采集数据的最小间隔。

webrtc::AudioDeviceModule 每次通过 webrtc::AudioTransport 送出 10 ms 的音频采集数据，因而小于 10 ms 的获取系统音频采集数据的周期没有太大意义。不同操作系统平台及不同的音频 API 接口，甚至运行相同操作系统相同音频 API 接口的不同具体设备，其获取系统音频采集数据的周期都会有一些差异。比如 Windows、Linux 和 Mac 一般都支持 10 ms 的获取系统音频采集数据周期，就像上面看到的 Mac 的那样，iOS 支持每次通过系统接口获取 512 或 1024 的每通道采样数的音频数据，Android 平台支持基于 AudioTrack/AudioRecord Java 接口、OpenSL ES 接口和 AAudio 接口实现的多种类型的 webrtc::AudioDeviceModule，不同的 Android 系统版本、不同的 webrtc::AudioDeviceModule 类型和不同的具体 Android 设备，获取系统音频采集数据的周期从 10 ms 到接近 200 ms 不等。

音频采集在 WebRTC 一对一语音通话中造成延迟，还可能出于 10 ms 音频数据帧的对齐。这主要发生在 iOS 操作系统平台。iOS 一般支持采样率 48kHz、32kHz 和 16kHz 等，其每个音频采集数据获取周期吐 512 或 1024 的每通道采样数难以和这些采样率下 10 ms 音频数据的整数倍的数据对齐，如采样率为 48kHz，10 ms 的数据为每通道 480 个样本数，512 的每通道采样数在吐出一个 10 ms 的音频数据帧之后，会多出 32 个采样数，这会造成额外的对齐延迟。

WebRTC 中 webrtc::AudioDeviceModule 的内部实现如下：

1661417037586.jpg

webrtc::AudioDeviceGeneric 的各个操作系统平台和音频 API 接口的子类，实现通过各个操作系统平台和音频 API 提供的接口，与音频设备交互。当获得的系统音频采集数据不是 10 ms 的数据时，如 iOS 和部分 Android 系统的一些实现，需要先把采集的数据放进一个缓冲区中，缓冲区的数据达到或超过 10 ms 的数据时，送 10 ms 的数据出去，直到缓冲区中的数据不足 10 ms，剩余的数据则等待下次有数据到达时，和下次到达的数据一起拼成 10 ms 的音频数据帧再送出去。这里的缓冲区在 WebRTC 中是 webrtc::FineAudioBuffer。

WebRTC 的 webrtc::AudioDeviceModule 中，先把采集数据通过 webrtc::FineAudioBuffer::DeliverRecordedData() 送进 webrtc::FineAudioBuffer，webrtc::FineAudioBuffer 将送进来的音频采集数据切成 10 ms 数据的音频帧，并通过 webrtc::AudioDeviceBuffer::SetRecordedBuffer() 和 webrtc::AudioDeviceBuffer::DeliverRecordedData() 送给 webrtc::AudioDeviceBuffer，webrtc::AudioDeviceBuffer 将 10 ms 数据的音频帧，借助于 webrtc::AudioTransport::RecordedDataIsAvailable() 通过 webrtc::AudioTransport 送出去。

对于音频采集延迟，两次获得系统音频采集数据的时间间隔是比较重要的指标。获得的系统音频采集数据不是 10 ms 的数据时，可以将 webrtc::FineAudioBuffer::DeliverRecordedData() 的两次调用间隔视作获得系统音频采集数据的间隔；平台支持获得 10 ms 的系统音频采集数据时，可以将 webrtc::AudioDeviceBuffer::DeliverRecordedData() 的两次调用间隔视作获得系统音频采集数据的间隔。

笔者在 webrtc::AudioDeviceBuffer 中加了一点点代码，来测 Windows 平台的两次获得系统音频采集数据的间隔，相关代码改动如下图：

Audio device delay

笔者用 Debug 版的二进制文件，在一台 Windows 10 笔记本电脑上跑简单的 WebRTC 一对一语音通话测试，跑了大概 10 分钟，总共获得 58491 条数据。对 WebRTC 一对一语音通话中音频端到端延迟影响比较大的，不仅仅是各个阶段的平均耗时，各个阶段耗时的异常值常常也会有比较大的影响。因而，这里统计音频采集延迟的数值分布，这些数据的数值分布统计结果如下表（延迟数据单位为 ms）：

Delay (ms)Item CountThe percentage
0530.000906
1100.000171
250.000085
390.000154
515870.027132
6110150.188320
725930.044332
87780.013301
92190.003744
1046770.079961
11165040.282163
12184470.315382
1321430.036638
143080.005266
15400.000684
16190.000325
1790.000154
1860.000103
1980.000137
20160.000274
21100.000171
2290.000154
23100.000171
2490.000154
2530.000051
2710.000017
2810.000017
2920.000034

从表中可以看到，在大多数情况下，两次获得系统音频采集数据的间隔都在 10 ms 左右，更准确地说，是集中在 5 ～ 14 ms 之间，但偶尔会有一些比较大的波动，这个间隔最大的时候可以达到 30 ms。

音频数据信号处理延迟

在 WebRTC 中，音频采集数据被送去编码的调用过程如下：

  * frame #0: webrtc::voe::(anonymous namespace)::ChannelSend::ProcessAndEncodeAudio(this=0x0000000107b1d810, audio_frame=<unavailable>) at channel_send.cc:809:3
    frame #1: webrtc::internal::AudioSendStream::SendAudioData(this=0x000000010f854200, audio_frame=nullptr) at audio_send_stream.cc:403:18
    frame #2: webrtc::AudioTransportImpl::SendProcessedData(this=0x0000000109024f10, audio_frame=nullptr) at audio_transport_impl.cc:190:30
    frame #3: webrtc::AudioTransportImpl::RecordedDataIsAvailable(this=0x0000000109024f10, audio_data=0x00000001079206b0, number_of_frames=480, bytes_per_sample=2, number_of_channels=1, sample_rate=48000, audio_delay_milliseconds=61, (null)=0, (null)=0, key_pressed=false, (null)=0x000070000db196ac) at audio_transport_impl.cc:171:5
    frame #4: webrtc::AudioDeviceBuffer::DeliverRecordedData(this=0x000000010790c678) at audio_device_buffer.cc:271:38
    frame #5: webrtc::AudioDeviceMac::CaptureWorkerThread(this=0x000000010800d200) at audio_device_mac.cc:2495:22
    frame #6: webrtc::AudioDeviceMac::StartRecording(this=0x0000000107c0a008)::$_1::operator()() const at audio_device_mac.cc:1314:16

采集的音频数据在被送去编码之前，还需要进行音频信号处理。在 webrtc::AudioTransport 实现的 RecordedDataIsAvailable() 函数中，把采集的音频数据送进 webrtc::AudioSendStream 编码之前，会先进行音频数据的信号处理，这也称为音频前处理。音频数据的信号处理主要包括回声消除（AEC）、降噪（ANS）和自动增益控制（AGC）等。

AudioTransportImpl::RecordedDataIsAvailable() 函数实现如下：

// Not used in Chromium. Process captured audio and distribute to all sending
// streams, and try to do this at the lowest possible sample rate.
int32_t AudioTransportImpl::RecordedDataIsAvailable(
    const void* audio_data,
    const size_t number_of_frames,
    const size_t bytes_per_sample,
    const size_t number_of_channels,
    const uint32_t sample_rate,
    const uint32_t audio_delay_milliseconds,
    const int32_t /*clock_drift*/,
    const uint32_t /*volume*/,
    const bool key_pressed,
    uint32_t& /*new_mic_volume*/) {  // NOLINT: to avoid changing APIs
  RTC_DCHECK(audio_data);
  RTC_DCHECK_GE(number_of_channels, 1);
  RTC_DCHECK_LE(number_of_channels, 2);
  RTC_DCHECK_EQ(2 * number_of_channels, bytes_per_sample);
  RTC_DCHECK_GE(sample_rate, AudioProcessing::NativeRate::kSampleRate8kHz);
  // 100 = 1 second / data duration (10 ms).
  RTC_DCHECK_EQ(number_of_frames * 100, sample_rate);
  RTC_DCHECK_LE(bytes_per_sample * number_of_frames * number_of_channels,
                AudioFrame::kMaxDataSizeBytes);

  int send_sample_rate_hz = 0;
  size_t send_num_channels = 0;
  bool swap_stereo_channels = false;
  {
    MutexLock lock(&capture_lock_);
    send_sample_rate_hz = send_sample_rate_hz_;
    send_num_channels = send_num_channels_;
    swap_stereo_channels = swap_stereo_channels_;
  }

  std::unique_ptr<AudioFrame> audio_frame(new AudioFrame());
  InitializeCaptureFrame(sample_rate, send_sample_rate_hz, number_of_channels,
                         send_num_channels, audio_frame.get());
  voe::RemixAndResample(static_cast<const int16_t*>(audio_data),
                        number_of_frames, number_of_channels, sample_rate,
                        &capture_resampler_, audio_frame.get());
  ProcessCaptureFrame(audio_delay_milliseconds, key_pressed,
                      swap_stereo_channels, audio_processing_,
                      audio_frame.get());

  // Typing detection (utilizes the APM/VAD decision). We let the VAD determine
  // if we're using this feature or not.
  // TODO(solenberg): GetConfig() takes a lock. Work around that.
  bool typing_detected = false;
  if (audio_processing_ &&
      audio_processing_->GetConfig().voice_detection.enabled) {
    if (audio_frame->vad_activity_ != AudioFrame::kVadUnknown) {
      bool vad_active = audio_frame->vad_activity_ == AudioFrame::kVadActive;
      typing_detected = typing_detection_.Process(key_pressed, vad_active);
    }
  }

  // Copy frame and push to each sending stream. The copy is required since an
  // encoding task will be posted internally to each stream.
  {
    MutexLock lock(&capture_lock_);
    typing_noise_detected_ = typing_detected;
  }

  RTC_DCHECK_GT(audio_frame->samples_per_channel_, 0);
  if (async_audio_processing_)
    async_audio_processing_->Process(std::move(audio_frame));
  else
    SendProcessedData(std::move(audio_frame));

  return 0;
}

void AudioTransportImpl::SendProcessedData(
    std::unique_ptr<AudioFrame> audio_frame) {
  RTC_DCHECK_GT(audio_frame->samples_per_channel_, 0);
  MutexLock lock(&capture_lock_);
  if (audio_senders_.empty())
    return;

  auto it = audio_senders_.begin();
  while (++it != audio_senders_.end()) {
    auto audio_frame_copy = std::make_unique<AudioFrame>();
    audio_frame_copy->CopyFrom(*audio_frame);
    (*it)->SendAudioData(std::move(audio_frame_copy));
  }
  // Send the original frame to the first stream w/o copying.
  (*audio_senders_.begin())->SendAudioData(std::move(audio_frame));
}

这里的音频数据信号处理为软件音频数据信号处理，如软件 AEC 等，即这些信号处理主要由集成的软件算法和库实现。这里的这些软件音频数据信号处理，常常是音频数据流水线上的 CPU 和内存资源消耗大户。音频数据信号处理造成的延迟，主要来源于这些信号处理繁重的 CPU 数据运算。然而许多设备和系统，本身为了支持电话/通话等场景，在系统集成了回声消除等音频数据信号处理。对于硬件音频数据信号处理，在实现上，设备和系统可能是在内部集成了软件音频数据信号处理的库，也可能设备本身带有专门的数字信号处理芯片。设备和系统支持的回声消除、降噪等音频数据信号处理，称为硬件 AEC 和硬件 ANS。Windows、Android 和 iOS 等系统都具有硬件 AEC 等功能。

设备和系统的硬件音频数字信号处理的优点是，比较高效，资源消耗较少，硬件 AEC 消除回声比较彻底，比如多个进程同时在播放声音，麦克风录制的声音经过硬件 AEC 可以消除掉这所有的回声，而对于软件 AEC，则只有当前进程播放的音频数据才有可能被消除等。硬件音频数字信号处理的缺点则是，难以调试分析和优化更新，对多场景的适应性一般，比如硬件 AEC 大多针对语音通话做优化，但在处理录制的音乐时，这种回声消除处理会对音质造成不太好的影响。相对的软件音频数据信号处理的优劣势也比较明显。

**音频数据信号处理延迟与操作系统、具体的设备及 WebRTC 的配置有关。当操作系统及设备支持并开启了硬件的回声消除、硬件的降噪等硬件音频数据信号处理，并关闭了软件的音频数据信号处理时，可以认为音频数据信号处理造成的延迟为 0。而开启了软件的音频数据信号处理，音频数据信号处理延迟则受设备的运算能力影响较大，但一般不会超过 5 ms。**笔者做测试的 Windows 10 笔记本电脑支持硬件音频数据信号处理，且配置了开启硬件音频数据信号处理，这里忽略音频数据信号处理的延迟。

音频编码延迟

在 WebRTC 中，采集到的音频数据由 webrtc::AudioDeviceModule 的采集线程一直送到 webrtc::voe::(anonymous namespace)::ChannelSend::ProcessAndEncodeAudio()，这个函数将音频数据转到一个专门的编码任务队列，异步地进行音频编码：

void ChannelSend::ProcessAndEncodeAudio(
    std::unique_ptr<AudioFrame> audio_frame) {
  RTC_DCHECK_RUNS_SERIALIZED(&audio_thread_race_checker_);
  RTC_DCHECK_GT(audio_frame->samples_per_channel_, 0);
  RTC_DCHECK_LE(audio_frame->num_channels_, 8);

  // Profile time between when the audio frame is added to the task queue and
  // when the task is actually executed.
  audio_frame->UpdateProfileTimeStamp();
  encoder_queue_.PostTask(
      [this, audio_frame = std::move(audio_frame)]() mutable {
        RTC_DCHECK_RUN_ON(&encoder_queue_);
        if (!encoder_queue_is_active_) {
          if (fixing_timestamp_stall_) {
            _timeStamp +=
                static_cast<uint32_t>(audio_frame->samples_per_channel_);
          }
          return;
        }
        // Measure time between when the audio frame is added to the task queue
        // and when the task is actually executed. Goal is to keep track of
        // unwanted extra latency added by the task queue.
        RTC_HISTOGRAM_COUNTS_10000("WebRTC.Audio.EncodingTaskQueueLatencyMs",
                                   audio_frame->ElapsedProfileTimeMs());

        bool is_muted = InputMute();
        AudioFrameOperations::Mute(audio_frame.get(), previous_frame_muted_,
                                   is_muted);

        if (_includeAudioLevelIndication) {
          size_t length =
              audio_frame->samples_per_channel_ * audio_frame->num_channels_;
          RTC_CHECK_LE(length, AudioFrame::kMaxDataSizeBytes);
          if (is_muted && previous_frame_muted_) {
            rms_level_.AnalyzeMuted(length);
          } else {
            rms_level_.Analyze(
                rtc::ArrayView<const int16_t>(audio_frame->data(), length));
          }
        }
        previous_frame_muted_ = is_muted;

        // Add 10ms of raw (PCM) audio data to the encoder @ 32kHz.

        // The ACM resamples internally.
        audio_frame->timestamp_ = _timeStamp;
        // This call will trigger AudioPacketizationCallback::SendData if
        // encoding is done and payload is ready for packetization and
        // transmission. Otherwise, it will return without invoking the
        // callback.
        if (audio_coding_->Add10MsData(*audio_frame) < 0) {
          RTC_DLOG(LS_ERROR) << "ACM::Add10MsData() failed.";
          return;
        }

        _timeStamp += static_cast<uint32_t>(audio_frame->samples_per_channel_);
      });
}

编码之后的音频帧，被打上 timestamp，被打包为音频 RTP 包，并被送进 pacing 模块等待发送，这个调用过程如下：

  * frame #0: webrtc::TaskQueuePacedSender::EnqueuePackets(this=0x000000010f823a00, packets=size=1) at task_queue_paced_sender.cc:130:3
    frame #1: webrtc::voe::(anonymous namespace)::RtpPacketSenderProxy::EnqueuePackets(this=0x000000010785e9e0, packets=size=0) at channel_send.cc:267:24
    frame #2: webrtc::RTPSender::SendToNetwork(this=0x000000010f83bc50, packet=nullptr) at rtp_sender.cc:491:18
    frame #3: webrtc::RTPSenderAudio::SendAudio(this=0x0000000107860b30, frame_type=kAudioFrameSpeech, payload_type='?', rtp_timestamp=2577682277, payload_data="ox", payload_size=69, absolute_capture_timestamp_ms=-1) at
rtp_sender_audio.cc:316:35
    frame #4: webrtc::voe::(anonymous namespace)::ChannelSend::SendRtpAudio(this=0x000000010785e6e0, frameType=kAudioFrameSpeech, payloadType='?', rtp_timestamp=0, payload=ArrayView<const unsigned char, -4711L> @ 0x00007000020f1b08, absolute_capture_timestamp_ms=-1) at channel_send.cc:439:27
    frame #5: webrtc::voe::(anonymous namespace)::ChannelSend::SendData(this=0x000000010785e6e0, frameType=kAudioFrameSpeech, payloadType='?', rtp_timestamp=0, payloadData="ox", payloadSize=69, absolute_capture_timestamp_ms=-1) at channel_send.cc:367:10
    frame #6:  webrtc::voe::(anonymous namespace)::ChannelSend::SendData(webrtc::AudioFrameType, unsigned char, unsigned int, unsigned char const*, unsigned long, long long) at channel_send.cc:0
    frame #7: webrtc::(anonymous namespace)::AudioCodingModuleImpl::Encode(this=0x000000010f83d200, input_data=0x000000010f83d208, absolute_capture_timestamp_ms=optional<long long> @ 0x00007000020f2290)::AudioCodingModuleImpl::InputData const&, absl::optional<long long>) at audio_coding_module.cc:304:32
    frame #8: webrtc::(anonymous namespace)::AudioCodingModuleImpl::Add10MsData(this=0x000000010f83d200, audio_frame=0x000000011580da00) at audio_coding_module.cc:341:16
    frame #9: webrtc::voe::(anonymous namespace)::ChannelSend::ProcessAndEncodeAudio(this=0x0000000107e0b3c8)::$_7::operator()() at channel_send.cc:857:28

音频编码延迟主要包括音频数据编码任务被丢进编码任务队列等待执行的时间，和音频编码操作的耗时。音频编码延迟可以通过统计音频数据编码任务对象的生命周期获得，我们可以对 webrtc/audio/channel_send.cc 做类似下面这样的修改来实现：

Audio encoding delay

对于音频编码，还需要注意的一个点是，webrtc::AudioDeviceModule 每次给 webrtc::AudioTransport 送 10 ms 的音频数据，但 WebRTC 默认的音频编码器 OPUS 的默认配置是，每次编码 20 ms 的数据，也就是每两帧的采集音频帧编码一帧的编码帧，webrtc::voe::(anonymous namespace)::ChannelSend::ProcessAndEncodeAudio() 中统计的编码延迟，有一半的统计记录，由于创建的音频数据编码任务只是把采集的音频数据放进音频编码器的缓冲区，而没有真正地执行编码操作，是没什么太大意义的。

笔者用 debug 版的二进制文件，在一台 Windows 10 笔记本电脑上，执行与上面测音频采集延迟时相同的测试用例，测 Windows 平台的音频编码延迟。测试用例跑了大概 10 分钟，总共获得了 58494 条数据，统计数据时将耗时超过 1 ms 或真正地执行了编码操作的记录统计进来，这些记录总共有 30764 条。我们同样主要关注音频编码延迟的数值分布，而不是简单的平均值。数据统计结果如下表（延迟数据单位为 us）：

Delay (us)Item CountThe percentage
077220.251008
1000224210.728806
20006040.019633
3000140.000455
400030.000098

从表中可以看到，98% 以上的情况中，音频编码延迟小于 2 ms，极少数情况会达到 4 ms，没有超过 5 ms 的记录。

编码音频包的发送延迟

前面我们看到，编码之后的音频包被送进 pacing 模块来做平滑发送。Pacing 模块中有两个 webrtc::RtpPacketPacer/webrtc::RtpPacketSender 的实现，分别为 webrtc::TaskQueuePacedSender 和 webrtc::PacedSender，默认为 webrtc::TaskQueuePacedSender。

以使用 webrtc::TaskQueuePacedSender 控制平滑发送为例，来看编码音频包的发送过程。音频编码模块通过 TaskQueuePacedSender::EnqueuePackets() 将编码音频包送进 webrtc::TaskQueuePacedSender，webrtc::TaskQueuePacedSender 立即在名为 TaskQueuePacedSender 的任务队列中起一个异步任务，将编码音频包送进 webrtc::PacingController 的包队列中，TaskQueuePacedSender::EnqueuePackets() 的实现如下：

void TaskQueuePacedSender::EnqueuePackets(
    std::vector<std::unique_ptr<RtpPacketToSend>> packets) {
#if RTC_TRACE_EVENTS_ENABLED
  TRACE_EVENT0(TRACE_DISABLED_BY_DEFAULT("webrtc"),
               "TaskQueuePacedSender::EnqueuePackets");
  for (auto& packet : packets) {
    TRACE_EVENT2(TRACE_DISABLED_BY_DEFAULT("webrtc"),
                 "TaskQueuePacedSender::EnqueuePackets::Loop",
                 "sequence_number", packet->SequenceNumber(), "rtp_timestamp",
                 packet->Timestamp());
  }
#endif

  task_queue_.PostTask([this, packets_ = std::move(packets)]() mutable {
    RTC_DCHECK_RUN_ON(&task_queue_);
    for (auto& packet : packets_) {
      packet_size_.Apply(1, packet->size());
      RTC_DCHECK_GE(packet->capture_time_ms(), 0);
      pacing_controller_.EnqueuePacket(std::move(packet));
    }
    MaybeProcessPackets(Timestamp::MinusInfinity());
  });
}

webrtc::TaskQueuePacedSender 将编码音频包送进 webrtc::PacingController 的包队列的调用过程如下：

  * frame #0: webrtc::PacingController::EnqueuePacketInternal(this=0x000000010f058e28, packet=webrtc::RtpPacketToSend @ 0x0000000106f24070, priority=1) at pacing_controller.cc:291:3
    frame #1: webrtc::PacingController::EnqueuePacket(this=0x000000010f058e28, packet=nullptr) at pacing_controller.cc:242:3
    frame #2: webrtc::TaskQueuePacedSender::EnqueuePackets(this=0x0000000107817d28)::$_9::operator()() at task_queue_paced_sender.cc:145:26

随后，在 TaskQueuePacedSender 任务队列中处理编码音频包并发送出去，这个调用过程如下：

  * frame #0: cricket::MediaChannel::SendRtp(this=0x00000001078162b0, data="\x90\xbfB", len=101, options=0x000070000db31220) at media_channel.cc:170:8
    frame #1: cricket::WebRtcVoiceMediaChannel::SendRtp(this=0x00000001078162b0, data="\x90\xbfB", len=101, options=0x000070000db31220) at webrtc_voice_engine.cc:2571:17
    frame #2: webrtc::RtpSenderEgress::SendPacketToNetwork(this=0x000000010e82bd78, packet=0x0000000106f24070, options=0x000070000db31220, pacing_info=0x000070000db32270) at rtp_sender_egress.cc:553:30
    frame #3: webrtc::RtpSenderEgress::SendPacket(this=0x000000010e82bd78, packet=0x0000000106f24070, pacing_info=0x000070000db32270) at rtp_sender_egress.cc:273:29
    frame #4: webrtc::ModuleRtpRtcpImpl2::TrySendPacket(this=0x000000010e82b400, packet=0x0000000106f24070, pacing_info=0x000070000db32270) at rtp_rtcp_impl2.cc:376:30
    frame #5: webrtc::PacketRouter::SendPacket(this=0x000000010f0586a0, packet=webrtc::RtpPacketToSend @ 0x0000000106f24070, cluster_info=0x000070000db32270) at packet_router.cc:160:20
    frame #6: webrtc::PacingController::ProcessPackets(this=0x000000010f058e28) at pacing_controller.cc:585:21
    frame #7: webrtc::TaskQueuePacedSender::MaybeProcessPackets(this=0x000000010f058e00, scheduled_process_time=Timestamp @ 0x000070000db32738) at task_queue_paced_sender.cc:234:24
    frame #8: webrtc::TaskQueuePacedSender::MaybeProcessPackets(this=0x0000000107d04098)::$_14::operator()() const at task_queue_paced_sender.cc:275:39

在 cricket::MediaChannel 中，编码音频包被转到网络线程 pc_network_thread 并发送出去：

void MediaChannel::SendRtp(const uint8_t* data,
                           size_t len,
                           const webrtc::PacketOptions& options) {
  auto send =
      [this, packet_id = options.packet_id,
       included_in_feedback = options.included_in_feedback,
       included_in_allocation = options.included_in_allocation,
       packet = rtc::CopyOnWriteBuffer(data, len, kMaxRtpPacketLen)]() mutable {
        rtc::PacketOptions rtc_options;
        rtc_options.packet_id = packet_id;
        if (DscpEnabled()) {
          rtc_options.dscp = PreferredDscp();
        }
        rtc_options.info_signaled_after_sent.included_in_feedback =
            included_in_feedback;
        rtc_options.info_signaled_after_sent.included_in_allocation =
            included_in_allocation;
        SendPacket(&packet, rtc_options);
      };

  // TODO(bugs.webrtc.org/11993): ModuleRtpRtcpImpl2 and related classes (e.g.
  // RTCPSender) aren't aware of the network thread and may trigger calls to
  // this function from different threads. Update those classes to keep
  // network traffic on the network thread.
  if (network_thread_->IsCurrent()) {
    send();
  } else {
    network_thread_->PostTask(ToQueuedTask(network_safety_, std::move(send)));
  }
}

void MediaChannel::SendRtcp(const uint8_t* data, size_t len) {
  auto send = [this, packet = rtc::CopyOnWriteBuffer(
                         data, len, kMaxRtpPacketLen)]() mutable {
    rtc::PacketOptions rtc_options;
    if (DscpEnabled()) {
      rtc_options.dscp = PreferredDscp();
    }
    SendRtcp(&packet, rtc_options);
  };

  if (network_thread_->IsCurrent()) {
    send();
  } else {
    network_thread_->PostTask(ToQueuedTask(network_safety_, std::move(send)));
  }
}

最终在网络线程 pc_network_thread 中，编码音频包被发送到网络：

  * frame #0: rtc::PhysicalSocket::DoSendTo(this=0x000000010781adc0, socket=7, buf="\x90\xbfB", len=111, flags=0, dest_addr=0x000070000dbb2bf8, addrlen=16) at physical_socket_server.cc:510:19
    frame #1: rtc::PhysicalSocket::SendTo(this=0x000000010781adc0, buffer=0x000000011200a000, length=111, addr=0x000000011480c9c8) at physical_socket_server.cc:375:7
    frame #2: rtc::AsyncUDPSocket::SendTo(this=0x000000010781b6c0, pv=0x000000011200a000, cb=111, addr=0x000000011480c9c8, options=0x000070000dbb33a8) at async_udp_socket.cc:84:22
    frame #3: cricket::UDPPort::SendTo(this=0x000000010e819600, data=0x000000011200a000, size=111, addr=0x000000011480c9c8, options=0x000070000dbb37a8, payload=true) at stun_port.cc:281:23
    frame #4: cricket::ProxyConnection::Send(this=0x000000011480c800, data=0x000000011200a000, size=111, options=0x000070000dbb37a8) at connection.cc:1371:14
    frame #5: cricket::P2PTransportChannel::SendPacket(this=0x000000010e815600, data="\x90\xbfB", len=111, options=0x000070000dbb44e8, flags=0) at p2p_transport_channel.cc:1616:36
    frame #6: cricket::DtlsTransport::SendPacket(this=0x0000000107814880, data="\x90\xbfB", size=111, options=0x000070000dbb44e8, flags=1) at dtls_transport.cc:417:32
    frame #7: webrtc::RtpTransport::SendPacket(this=0x000000010e817c00, rtcp=false, packet=0x0000000107b08608, options=0x000070000dbb44e8, flags=1) at rtp_transport.cc:147:24
    frame #8: webrtc::SrtpTransport::SendRtpPacket(this=0x000000010e817c00, packet=0x0000000107b08608, options=0x000070000dbb56d0, flags=1) at srtp_transport.cc:173:10
    frame #9: cricket::BaseChannel::SendPacket(this=0x00000001078168c0, rtcp=false, packet=0x0000000107b08608, options=0x000070000dbb56d0) at channel.cc:437:33
    frame #10: cricket::BaseChannel::SendPacket(this=0x00000001078168c0, packet=0x0000000107b08608, options=0x000070000dbb56d0) at channel.cc:318:10
    frame #11: cricket::MediaChannel::DoSendPacket(this=0x00000001078162b0, packet=0x0000000107b08608, rtcp=false, options=0x000070000dbb56d0) at media_channel.cc:163:40
    frame #12: cricket::MediaChannel::SendPacket(this=0x00000001078162b0, packet=0x0000000107b08608, options=0x000070000dbb56d0) at media_channel.cc:71:10
    frame #13: cricket::MediaChannel::SendRtp(this=0x0000000107b085f8)::$_2::operator()() at media_channel.cc:184:9

在逻辑上，编码音频包的发送过程可以看作包含 5 个阶段，这 5 个阶段由两个线程接力完成：

  1. 编码音频包被送进 webrtc::TaskQueuePacedSender，webrtc::TaskQueuePacedSender 在 TaskQueuePacedSender 任务队列中起任务将编码音频包放进 webrtc::PacingController 的包队列中；
  2. 编码音频包在 webrtc::PacingController 的包队列中待一段时间等着被处理；
  3. webrtc::PacingController 的包队列中的编码音频包在 TaskQueuePacedSender 任务队列中被处理，并被转到网络线程 pc_network_thread 中等待被发送；
  4. 编码音频包在网络线程 pc_network_thread 的任务队列中待一段时间；
  5. 编码音频包被网络线程 pc_network_thread 发送到网络。

编码音频包的发送延迟可以认为是编码音频包进入 webrtc::TaskQueuePacedSender 到 cricket::MediaChannel 向网络线程 pc_network_thread 中抛的编码音频包发送任务执行结束的时长。这个时长可以通过打多个点来计算：在 TaskQueuePacedSender::EnqueuePackets() 打点记录编码音频包的 timestamp 和时间戳，这个时候编码音频包还没有有效的 sequence number；在 RtpSenderEgress::SendPacket() 打点记录编码音频包的 timestamp 和 sequence number，以建立编码音频包的 timestamp 和 sequence number 之间的关联；在 MediaChannel::SendRtp() 中，编码音频包发送任务执行结束后，打点记录编码音频包的 sequence number 和时间戳。

由于在 TaskQueuePacedSender::EnqueuePackets() 中，编码音频包还没有有效的 sequence number 而只能访问编码音频包的 timestamp，在 MediaChannel::SendRtp() 中，访问编码音频包的 sequence number 比较方便，故需要在 RtpSenderEgress::SendPacket() 打点建立编码音频包的 timestamp 和 sequence number 之间的关联。

统计编码音频包发送延迟相关的具体改动如下：

Audio send delay

笔者用 debug 版的二进制文件，在笔者的一台 Mac 笔记本电脑上跑简单的 WebRTC 一对一语音通话用例，运行大概 10 分钟，总共获得 24483 条数据。同样，我们主要关注编码音频包发送延迟的数值分布，对这些数据的统计结果如下表（延迟数据单位为 ms）：

DelayItem CountThe percentage
0150350.604228
194850.381184
2440.001768
3500.002009
4560.002251
5270.001085
6230.000924
7240.000965
8250.001005
9160.000643
10100.000402
1150.000201
1240.000161
13110.000442
1440.000161
15120.000482
16170.000683
17140.000563
18150.000603
1910.000040
2030.000121
2310.000040
4110.000040

在表中可以看到，98% 以上的情况中，编码音频包发送延迟小于 2 ms，但这一延迟也会有一些波动，这一延迟的最大值甚至可以达到 41 ms。

编码音频包网络传输延迟

由于互联网环境的错综复杂，编码音频包网络传输延迟常常是音频端到端延迟比较重要的组成部分。这部分延迟，可以认为是在 cricket::MediaChannel 中，创建的网络线程 pc_network_thread 上的编码音频包发送任务执行结束，到接收端从网络上收到编码音频包之间的时间。

如果发送端和接收端运行于不同的机器，则两台机器的时钟难以保持绝对同步，这会给网络传输延迟的统计造成一些障碍。即使两台机器通过相同的时钟源来校准，基于编码音频包的发送 NTP 时间和接收 NTP 时间来统计网络传输延迟，也会由于校准的精度问题，而使统计的网络传输延迟存在一定的可见的误差。

统计网络传输延迟，最好的方法还是在同一台机器上既运行发送端，也运行接收端，从而基于同一个时钟来计算。

编码音频包在整个发送、传输和接收过程中，timestamp 保持不变，因而可以通过编码音频包的 timestamp 来关联发送的包和接收的包。

接收端编码音频包的接收过程主要为，在网络线程中，从网络上接收编码音频包，随后在 worker thread 中把编码音频包放进 NetEq 的 PacketBuffer 里。

网络线程 pc_network_thread 中，从网络接收编码音频包并向 NetEQ 传递的调用过程为：

* thread #6, name = 'pc_network_thread', stop reason = breakpoint 2.1
  * frame #0: cricket::WebRtcVoiceMediaChannel::OnPacketReceived(this=0x0000000107d07040, packet=<unavailable>, packet_time_us=6039635487554) at webrtc_voice_engine.cc:2216:3
    frame #1: cricket::BaseChannel::OnRtpPacket(this=0x0000000107d060b0, parsed_packet=0x000070000361acd0) at channel.cc:467:19
    frame #2: webrtc::RtpDemuxer::OnRtpPacket(this=0x000000010882cb70, packet=0x000070000361acd0) at rtp_demuxer.cc:249:11
    frame #3: webrtc::RtpTransport::DemuxPacket(this=0x000000010882ca00, packet=CopyOnWriteBuffer @ 0x000070000361b2e0, packet_time_us=6039635487554) at rtp_transport.cc:194:21
    frame #4: webrtc::SrtpTransport::OnRtpPacketReceived(this=0x000000010882ca00, packet=CopyOnWriteBuffer @ 0x000070000361b820, packet_time_us=6039635487554) at srtp_transport.cc:226:3
    frame #5: webrtc::RtpTransport::OnReadPacket(this=0x000000010882ca00, transport=0x0000000107839470, data="\x90?", len=147, packet_time_us=0x000070000361d078, flags=1) at rtp_transport.cc:268:5
    frame #10: cricket::DtlsTransport::OnReadPacket(this=0x0000000107839470, transport=0x0000000108826c00, data="\x90?", size=147, packet_time_us=0x000070000361d078, flags=0) at dtls_transport.cc:627:9
    frame #15: cricket::P2PTransportChannel::OnReadPacket(this=0x0000000108826c00, connection=0x0000000114008800, data="\x90?", len=147, packet_time_us=6039635487554) at p2p_transport_channel.cc:2215:5
    frame #20: cricket::Connection::OnReadPacket(this=0x0000000114008800, data="\x90?", size=147, packet_time_us=6039635487554) at connection.cc:465:5
    frame #21: cricket::UDPPort::OnReadPacket(this=0x000000010f06f800, socket=0x0000000107b4cfb0, data="\x90?", size=147, remote_addr=0x000070000361e480, packet_time_us=0x000070000361dd30) at stun_port.cc:389:11
    frame #22: cricket::UDPPort::HandleIncomingPacket(this=0x000000010f06f800, socket=0x0000000107b4cfb0, data="\x90?", size=147, remote_addr=0x000070000361e480, packet_time_us=6039635487554) at stun_port.cc:330:3
    frame #23: cricket::AllocationSequence::OnReadPacket(this=0x0000000107b4cbe0, socket=0x0000000107b4cfb0, data="\x90?", size=147, remote_addr=0x000070000361e480, packet_time_us=0x000070000361e2d8) at basic_port_allocator.cc:1639:18
    frame #28: rtc::AsyncUDPSocket::OnReadEvent(this=0x0000000107b4cfb0, socket=0x0000000107b4cd70) at async_udp_socket.cc:132:3
    frame #33: rtc::SocketDispatcher::OnEvent(this=0x0000000107b4cd70, ff=1, err=0) at physical_socket_server.cc:842:5
    frame #34: rtc::ProcessEvents(dispatcher=0x0000000107b4cd70, readable=true, writable=false, error_event=false, check_error=true) at physical_socket_server.cc:1249:17
    frame #35: rtc::PhysicalSocketServer::WaitSelect(this=0x0000000106f08570, cmsWait=32, process_io=true) at physical_socket_server.cc:1357:9
    frame #36: rtc::PhysicalSocketServer::Wait(this=0x0000000106f08570, cmsWait=32, process_io=true) at physical_socket_server.cc:1183:10

WebRtcVoiceMediaChannel::OnPacketReceived() 将接收到的编码音频包转到 worker thread，并送进 NetEQ：

void WebRtcVoiceMediaChannel::OnPacketReceived(rtc::CopyOnWriteBuffer packet,
                                               int64_t packet_time_us) {
  RTC_DCHECK_RUN_ON(&network_thread_checker_);
  // TODO(bugs.webrtc.org/11993): This code is very similar to what
  // WebRtcVideoChannel::OnPacketReceived does. For maintainability and
  // consistency it would be good to move the interaction with call_->Receiver()
  // to a common implementation and provide a callback on the worker thread
  // for the exception case (DELIVERY_UNKNOWN_SSRC) and how retry is attempted.
  worker_thread_->PostTask(ToQueuedTask(task_safety_, [this, packet,
                                                       packet_time_us] {
    RTC_DCHECK_RUN_ON(worker_thread_);

    webrtc::PacketReceiver::DeliveryStatus delivery_result =
        call_->Receiver()->DeliverPacket(webrtc::MediaType::AUDIO, packet,
                                         packet_time_us);

    if (delivery_result != webrtc::PacketReceiver::DELIVERY_UNKNOWN_SSRC) {
      return;
    }

    // Create an unsignaled receive stream for this previously not received
    // ssrc. If there already is N unsignaled receive streams, delete the
    // oldest. See: https://bugs.chromium.org/p/webrtc/issues/detail?id=5208
    uint32_t ssrc = ParseRtpSsrc(packet);
    RTC_DCHECK(!absl::c_linear_search(unsignaled_recv_ssrcs_, ssrc));

    // Add new stream.
    StreamParams sp = unsignaled_stream_params_;
    sp.ssrcs.push_back(ssrc);
    RTC_LOG(LS_INFO) << "Creating unsignaled receive stream for SSRC=" << ssrc;
    if (!AddRecvStream(sp)) {
      RTC_LOG(LS_WARNING) << "Could not create unsignaled receive stream.";
      return;
    }
    unsignaled_recv_ssrcs_.push_back(ssrc);
    RTC_HISTOGRAM_COUNTS_LINEAR("WebRTC.Audio.NumOfUnsignaledStreams",
                                unsignaled_recv_ssrcs_.size(), 1, 100, 101);

    // Remove oldest unsignaled stream, if we have too many.
    if (unsignaled_recv_ssrcs_.size() > kMaxUnsignaledRecvStreams) {
      uint32_t remove_ssrc = unsignaled_recv_ssrcs_.front();
      RTC_DLOG(LS_INFO) << "Removing unsignaled receive stream with SSRC="
                        << remove_ssrc;
      RemoveRecvStream(remove_ssrc);
    }
    RTC_DCHECK_GE(kMaxUnsignaledRecvStreams, unsignaled_recv_ssrcs_.size());

    SetOutputVolume(ssrc, default_recv_volume_);
    SetBaseMinimumPlayoutDelayMs(ssrc, default_recv_base_minimum_delay_ms_);

    // The default sink can only be attached to one stream at a time, so we hook
    // it up to the *latest* unsignaled stream we've seen, in order to support
    // the case where the SSRC of one unsignaled stream changes.
    if (default_sink_) {
      for (uint32_t drop_ssrc : unsignaled_recv_ssrcs_) {
        auto it = recv_streams_.find(drop_ssrc);
        it->second->SetRawAudioSink(nullptr);
      }
      std::unique_ptr<webrtc::AudioSinkInterface> proxy_sink(
          new ProxySink(default_sink_.get()));
      SetRawAudioSink(ssrc, std::move(proxy_sink));
    }

    delivery_result = call_->Receiver()->DeliverPacket(webrtc::MediaType::AUDIO,
                                                       packet, packet_time_us);
    RTC_DCHECK_NE(webrtc::PacketReceiver::DELIVERY_UNKNOWN_SSRC,
                  delivery_result);
  }));
}

WebRtcVoiceMediaChannel::OnPacketReceived() 将接收到的编码音频包在 worker thread 上送进 NetEQ 的调用过程如下：

* thread #5, name = 'Thread 0x0x10780af20', stop reason = breakpoint 1.1
  * frame #0: webrtc::PacketBuffer::InsertPacket(this=0x0000000107b49080, packet=0x0000000106f9cea0, stats=0x0000000107b48de0, last_decoded_length=480, sample_rate=16000, target_level_ms=80, decoder_database=0x0000000107b49030) at packet_buffer.cc:140:7
    frame #1: webrtc::PacketBuffer::InsertPacketList(this=0x0000000107b49080, packet_list=0x0000700003598948 size=1, decoder_database=0x0000000107b49030, current_rtp_payload_type=0x0000000107b498ad, current_cng_rtp_payload_type=0x0000000107b498af, stats=0x0000000107b48de0, last_decoded_length=480, sample_rate=16000, target_level_ms=80) at packet_buffer.cc:243:9
    frame #2: webrtc::NetEqImpl::InsertPacketInternal(this=0x0000000107b49750, rtp_header=0x0000700003599ea0, payload=ArrayView<const unsigned char, -4711L> @ 0x0000700003598af0) at neteq_impl.cc:690:35
    frame #3: webrtc::NetEqImpl::InsertPacket(this=0x0000000107b49750, rtp_header=0x0000700003599ea0, payload=ArrayView<const unsigned char, -4711L> @ 0x0000700003598d48) at neteq_impl.cc:170:7
    frame #4: webrtc::acm2::AcmReceiver::InsertPacket(this=0x000000010f067210, rtp_header=0x0000700003599ea0, incoming_payload=ArrayView<const unsigned char, -4711L> @ 0x00007000035993f8) at acm_receiver.cc:136:15
    frame #5: webrtc::voe::(anonymous namespace)::ChannelReceive::OnReceivedPayloadData(this=0x000000010f067000, payload=ArrayView<const unsigned char, -4711L> @ 0x0000700003599758, rtpHeader=0x0000700003599ea0) at channel_receive.cc:340:21
    frame #6: webrtc::voe::(anonymous namespace)::ChannelReceive::ReceivePacket(this=0x000000010f067000, packet="\x90\xbf", packet_length=99, header=0x0000700003599ea0) at channel_receive.cc:719:5
    frame #7: webrtc::voe::(anonymous namespace)::ChannelReceive::OnRtpPacket(this=0x000000010f067000, packet=0x000070000359a7a0) at channel_receive.cc:669:3
    frame #8: webrtc::RtpDemuxer::OnRtpPacket(this=0x00000001070122b0, packet=0x000070000359a7a0) at rtp_demuxer.cc:249:11
    frame #9: webrtc::RtpStreamReceiverController::OnRtpPacket(this=0x0000000107012238, packet=0x000070000359a7a0) at rtp_stream_receiver_controller.cc:52:19
    frame #10: webrtc::internal::Call::DeliverRtp(this=0x0000000107012000, media_type=AUDIO, packet=CopyOnWriteBuffer @ 0x000070000359aa18, packet_time_us=6039178656533) at call.cc:1606:36
    frame #11: webrtc::internal::Call::DeliverPacket(this=0x0000000107012000, media_type=AUDIO, packet=CopyOnWriteBuffer @ 0x000070000359b4a8, packet_time_us=6039178656533) at call.cc:1637:10
    frame #12: cricket::WebRtcVoiceMediaChannel::OnPacketReceived(this=0x0000000106f9cc48)::$_3::operator()() const at webrtc_voice_engine.cc:2227:28

编码音频包网络传输延迟通过编码音频包的发送完成时间和接收开始时间来统计。为了能将发送的编码音频包和接收的编码音频包关联起来，需要获得编码音频包的 timestamp，timestamp 在编码音频包经过解密和解析之后访问起来比较方便。由上面的编码音频包接收过程可以看到，cricket::BaseChannel::OnRtpPacket() 无疑是做这种统计最合适的点。

统计编码音频包的发送时间点的方法如上面那样，这里在 cricket::BaseChannel::OnRtpPacket() 加上统计编码音频包的接收时间的逻辑。整体的改动如下：

Audio network transport delay

笔者用 debug 版的二进制文件，在一台 Windows 10 笔记本电脑上跑简单的 WebRTC 一对一语音通话用例，发送端和接收端跑在同一台机器上，跑了大概 10 分钟，总共获得 27111 条数据。同样主要关注编码音频包网络传输延迟的数值分布，对这些数据的统计结果如下表（延迟数据单位为 ms）：

DelayItem CountThe percentage
(0-5]1320.004869
(5-10]54080.199476
(10-15]73620.271550
(15-20]46440.171296
(20-35]66500.245288
(35-60]24760.091328
(60-100]3820.014090
(100-…]570.002102

在笔者的网络环境中，绝大部分的编码音频包网络端到端传输延迟在 5 ～ 60 ms。

WebRtcVoiceMediaChannel::OnPacketReceived() 将接收到的编码音频包转到 worker thread 上，这是让控制线程干了一些数据流的活。接收到的编码音频包的转线程及将编码音频包送进 NetEQ 的过程，一般来说对于音频端到端延迟不会造成可见的影响，因而这个过程的时间忽略不计。

解码等待延迟

解码过程是由 webrtc::AudioDeviceModule 内的播放线程驱动的。webrtc::AudioDeviceModule 内会起一个播放线程，它定时地通过回调从 NetEQ 拿解码后的音频数据。送进 NetEQ 的编码音频包不会立即被拿去解码，而是要等播放线程的回调请求时，才会真正的解码。

在编码音频包被插入 NetEQ 的包队列，到编码音频包被拿来解码，通常需要经过一段时间。WebRTC 在 NetEQ 中会统计编码音频包从接收到解码经过的等待时间，并会计算编码音频包的平均等待时间。我们主要关注的还是这个等待时间的分布，及不同延迟值范围的分布和比例，而不仅仅是平均等待时间。我们可以在 NetEQ 中把各个编码音频包的等待解码时间吐出来。相关改动如下：

Audio packet waiting time

笔者用 debug 版的二进制文件，在笔者的一台 Windows 10 笔记本电脑上跑简单的 WebRTC 一对一语音通话用例，跑了大概 10 分钟，在接收端总共获得 27123 条数据，各个编码音频包等待解码时间分布如下表（延迟数据单位为 ms）：

DelayItem CountThe percentage
102140.007890
202600.009586
308160.030085
4017960.066217
5041490.152970
6081620.300925
7077750.286657
8024090.088818
907670.028279
1002980.010987
1101860.006858
120630.002323
130730.002691
140320.001180
150220.000811
160220.000811
170170.000627
18070.000258
19030.000111
20040.000147
21080.000295
220120.000442
23040.000147
24070.000258
25050.000184
26020.000074
27030.000111
28040.000147
29020.000074
31010.000037

编码音频包等待解码时间大多在 20 ～ 100 ms，但也会有一些比较大的值，最大的甚至达到了 310 ms。

音频解码及播放延迟

播放线程的回调调上来时，会完成一系列操作：

  1. 对所有的远端音频流做解码、PLC；
  2. 根据各个远端音频流的采样率计算获得一个音频采样率；
  3. 将所有的远端音频流重采样到计算获得的音频采样率；
  4. 统一各个远端音频流的通道数，选择音强最强的几个音频流，做混音；
  5. 将混音之后的音频数据重采样到音频设备支持的采样率和通道数；
  6. 将重采样之后的数据送进设备播放出来。

上面的整个过程可以认为是在 AudioTransportImpl::NeedMorePlayData() 中串起来的，其中的第 1 ~ 4 步可以认为是藉由 AudioMixer 串起来的：

// Mix all received streams, feed the result to the AudioProcessing module, then
// resample the result to the requested output rate.
int32_t AudioTransportImpl::NeedMorePlayData(const size_t nSamples,
                                             const size_t nBytesPerSample,
                                             const size_t nChannels,
                                             const uint32_t samplesPerSec,
                                             void* audioSamples,
                                             size_t& nSamplesOut,
                                             int64_t* elapsed_time_ms,
                                             int64_t* ntp_time_ms) {
  RTC_DCHECK_EQ(sizeof(int16_t) * nChannels, nBytesPerSample);
  RTC_DCHECK_GE(nChannels, 1);
  RTC_DCHECK_LE(nChannels, 2);
  RTC_DCHECK_GE(
      samplesPerSec,
      static_cast<uint32_t>(AudioProcessing::NativeRate::kSampleRate8kHz));

  // 100 = 1 second / data duration (10 ms).
  RTC_DCHECK_EQ(nSamples * 100, samplesPerSec);
  RTC_DCHECK_LE(nBytesPerSample * nSamples * nChannels,
                AudioFrame::kMaxDataSizeBytes);

  mixer_->Mix(nChannels, &mixed_frame_);
  *elapsed_time_ms = mixed_frame_.elapsed_time_ms_;
  *ntp_time_ms = mixed_frame_.ntp_time_ms_;

  if (audio_processing_) {
    const auto error =
        ProcessReverseAudioFrame(audio_processing_, &mixed_frame_);
    RTC_DCHECK_EQ(error, AudioProcessing::kNoError);
  }

  nSamplesOut = Resample(mixed_frame_, samplesPerSec, &render_resampler_,
                         static_cast<int16_t*>(audioSamples));
  RTC_DCHECK_EQ(nSamplesOut, nChannels * nSamples);
  return 0;
}

音频播放延迟的来源，与我们前面在 音频采集延迟 中见到的类似，主要来源于两次播放数据请求的回调之间的时间间隔。音频播放延迟的统计方法也与音频采集延迟的统计方法类似，前面看到的音频采集延迟统计的相关改动中也包含了统计音频播放延迟相关的逻辑。

这里我们增加统计 AudioMixer 中的各种操作的耗时，和混音之后的音频数据重采样的耗时的逻辑。相关的改动如：

Decoding and resampling delay

笔者用 debug 版的二进制文件，在笔者的一台 Windows 10 笔记本电脑上跑简单的 WebRTC 一对一语音通话用例，跑了大概 10 分钟，在接收端总共获得 52956 条两次播放回调间时间间隔的数据，这些时间间隔的分布如下表（延迟数据单位为 ms）：

DelayItem CountThe percentage
050.000094
1520.000982
2430.000812
31080.002039
41820.003437
52750.005193
62910.005495
73240.006118
815620.029496
9123180.232608
10225540.425901
11123620.233439
1215690.029628
133650.006893
143210.006062
152770.005231
161490.002814
17890.001681
18550.001039
19350.000661
20120.000227
2130.000057
2220.000038
2310.000019
2910.000019
3510.000019

从表中可以看到，绝大部分的时间间隔在 8 ~ 12 ms 之间。偶尔会有一些超过的，最高的在 35 ms。

相同的测试获得 52957 条 AudioMixer 的一系列操作的耗时的数据，我们主要关注这些数据的数值分布，这些数据统计结果如下表（延迟数据单位为 us）：

DelayItem CountThe percentage
0375380.708839
1000144000.271919
20006010.011349
30001270.002398
4000750.001416
5000760.001435
6000490.000925
7000470.000888
8000210.000397
9000180.000340
1000030.000057
1100020.000038

从表中可以看到，超过 98% 的耗时都在 2000 us，也就是 2 ms 以内。（受限于系统时间接口的精度，延迟时间的精度只能达到 ms 级）。

然后是混音之后的音频数据的重采样耗时。相同测试中获得 52957 条数据记录，统计结果如下表（延迟数据单位为 us）：

DelayItem CountThe percentage
0528890.998716
1000680.001284

尽管重采样属于语音通话中音频端到端数据处理过程中比较消耗资源的操作，但耗时基本上都没有超过 1 ms。

从上面获得的 WebRTC 一对一语音通话中音频端到端分段延迟的数据可以看到，对于端到端延迟影响比较大的过程包括：音频采集，编码音频包在网络中的传输，音频包在缓冲区中等待被解码处理，音频播放等。但其它过程，如编码音频包的发送，偶尔会出现一些比较大的异常延迟值。音频编码成为音频端到端延迟瓶颈的可能性在于，编码音频帧时长的配置，音频编码操作本身耗时有限。

尽管笔者这里的分析都基于 debug 版的二进制文件进行，这可能会造成一些额外的资源消耗，但统计数据的数量级上是不会有什么差别的。

WebRTC 一对一语音通话中音频端到端分段延迟大体如上。

这里的分析的代码基于 WebRTC M98 版的代码进行（OpenRTCClient），文中所用的数据分析脚本，可以参考 e2e_delay_analysis.py

Done。

hanpfei
关注
专栏目录
webrtc(native C++)+srs(sfu)测延时200ms
宝安小雨
04-20 2477
srs集成了信令服务器的功能 srs没有打洞功能，推拉流端与它连接时需要手动设置CANDIDATE，把自己的公网ip暴露给srs，这样推拉流两端都和srs建立了p2p，这就是sfu的模型，one-to-many，suf服务器会把接收到的流分发给其他参与者。 参考： peerconnection_client实现srs推拉流 sfu原理 .........
深入探究音视频开源库WebRTC中NetEQ音频抗网络延时与抗丢包的实现机制
最新发布
dvlinker的技术专栏
04-24 1万+
深入探究音视频开源库WebRTC中NetEQ音频抗网络延时与抗丢包的实现机制
webrtc延迟分析
zhuiyuanqingya的博客
07-19 7069
1.webrtc加密概述 2.webrtc加密对传输效率的影响 3.取消加密的可行性
WebRTC 客户端ICE 延迟问题
RTC hacker
06-06 6203
本文原创自 http://blog.csdn.net/voipmaker  转载注明出处。         最近在优化WebRTC客户端呼叫延迟问题，原因是ICE协议栈在收集地址到探测协商过程花费很长时间，这在VOIP里是不可容忍的，有人直接把ICE 功能关掉，这样做解决了延迟问题，但是NAT穿越失效，媒体必须走服务器，这在一些webrtc与sip系统互通的系统中有应用价值，但两个webrt
webrtc 共享屏幕延时测试
zhuiyuanqingya的博客
08-20 9540
1.可能导致延时的因素 音频对延时的影响，音频的处理耗时，以及音视频同步耗时 视频抖动缓冲延时，在局域网内，如果缩小抖动缓冲区，可能会减少延时 2.在共享屏幕的时候不共享音频...
web播放rtsp流视频，使用webrtc毫秒级延迟
qq_53200007的博客
09-19 9696
在web中使用webrtc实现毫秒级延迟播放摄像头rtsp视频流
WebRTC视频数据统计之延时、抖动与丢包
04-25
WebRTC视频数据统计之延时、抖动与丢包，包含WebRTC如何更新、客户端如何获取等流程结构图
vue3实现WebRTC实战1v1通话
09-01
在"1对1视频通话示例"中，我们将探讨如何利用Vue3和WebRTC创建一个简单的1v1视频聊天应用。这个过程涉及到多个关键步骤和技术： 1. **安装和设置Vue3项目**：首先，你需要安装Vue CLI并创建一个新的Vue3项目。使用`...
基于java开发环境的WebRTC 点对点视频通话系统
07-20
在这个基于Java开发环境的WebRTC点对点视频通话系统中，我们将深入探讨如何利用Java和WebRTC构建一个实时音视频通话应用。 首先，Java是一种广泛使用的编程语言，尤其在服务器端开发领域。然而，WebRTC主要是为...
WebRTC语音视频通话demo
12-21
在本“WebRTC语音视频通话demo”中，我们将探讨WebRTC如何实现网页端和移动端的语音和视频通话功能。 首先，WebRTC技术基于一系列标准化协议，如Session Description Protocol (SDP)、Interactive Connectivity ...
webrtc回声消除原理及延时估算方法.pdf
04-13
刚完成一个语音相关的项目，简单的总结了一下webrtc回声消除的原理，以及时间延时估算方法，希望对大家有所帮助。
基于WebRTC+SpringBoot+Websocket 简单音视频通话
05-12
相关技术：Websocket，Springboot，WebRtc 使用Websocket 作为交互，作为信令服务器，负责信令交换。 视频、麦克风、屏幕共享相关操作，下载即可运行。 包含使用手册及相关说明。
webRTC中音频相关的netEQ（三）：存取包和延时计算
weixin_30305735的博客
08-20 556
上篇（webRTC中音频相关的netEQ（二）：数据结构）讲了netEQ里主要的数据结构，为理解netEQ的机制打好了基础。本篇主要讲MCU中从网络上收到的RTP包是怎么放进packet buffer和从packet buffer里取出来，以及网络延时值（optBufLevel）和抖动缓冲延时值（buffLevelFilt）的计算。先看RTP语音包是怎么放进packet buffer的。 ...
webrtc QOS笔记三 RTT计算，SRS增加XR
靑い空゛
03-22 1290
完整NTP时间戳用64bits表示，左半32bits表示整数，右半32bits表示小数，一般为了紧凑，取中间32bits表示即可，这时整数与小数分别16bits表示）。记录着上次源SSRC_n发送SR的NTP时间，从收到的SR记录的NTP时间戳获取。记录着上次源SSRC_n发送Receiver Reference Time Report Block的NTP时间，从收到的Receiver Reference Time Report Block记录的NTP时间戳获取。记录着发送该SR的NTP时间戳。
为何公众号推送会延迟发送_基于WebRTC构建超低延迟(500ms)的直播系统
weixin_39895167的博客
10-27 181
上周写了一篇文章基于RTMP和WebRTC 构建低延迟的直播系统(https://zhuanlan.zhihu.com/p/47302561), 只所以要基于RTMP, 还是考虑尽可能复用现有的技术和基础设施. 实际上国外已经有基于WebRTC的CDN系统, 比如 http://phenixrts.com/, https://www.millicast.com/. 比这更早的可以追溯到beam,...
WebRTC降低直播延迟优化
程序猿老樊的博客
03-31 4100
摘要 曾经点播在视频传输中占据很大的比例，但如今越来越多的平台希望能够通过直播的方式增加观众的兴奋程度和参与度，同时直播时的延迟成为了一个关键的挑战。在音视频传输的过程中，在不同阶段都会产生延时，有设备端上的延时，设备端与服务器之间的延时，服务器之间的延时，但是，不同的行业对于实时音视频的延迟也有不同的要求，需要找到画质、音质、延时和功耗等方面的平衡点。 在线视频传输行业的发展 从2016年到2017年，每周观看超过10小时在线视频的用户数量从9.8%增加到17%。而在同一时期，每周仅观看一到两小时视
SRS gb28181 流媒体 搭建及webrtc播放延迟1s
2201_76108770的博客
02-16 532
最近在研究流媒体,于是就找到了srs开源框架, 国标仓库是另外一个地址。webrtc效果 具有低延迟性, 延迟时间在 100ms-300ms。8.到此gb28181流媒体就搭建完毕了,你可以尽情享受了。如果下载慢的话可以直接 点击 Download ZIP。点击预览, 注意我这里配置了摄像机,所以会有视频。6.找一台摄像机,以海康球机为例 登录海康摄像机。2.将下载好的文件放在服务器上进行解压。4.漫长等待之后编译完毕修改配置文件。如果你不能访问请下载我的代码。3.进入文件夹 编译。7.然后去控制台预览。
SRS流媒体服务（四）WebRTC实现实时视频通话和低延时互动直播
weixin_44341110的博客
08-17 4796
使用webRTC API实现实时的视频通话和低延时互动直播
webrtc黑盒延时测试
zhuiyuanqingya的博客
07-20 1239
声明：本文翻译自BLACK BOX DELAY TESTING OF WEBRTC 1.服务质量与延时 VoIP应用的3个主要服务质量维度分别是：网络抖动、丢包率和发送端到接收端的延迟。 延迟相关建议： 0-150ms 是可以接受的 150-400ms 可以接受，但是会影响通话质量 超过400ms 通常是不可接受的 备注：M2E（mouth-to-ear） 2.webrtc...
vue一对一语音通话
10-25
Vue一对一语音通话是指使用Vue框架开发的一种实时语音通信技术，可以实现两个用户之间的实时语音通话。在Vue中，可以使用WebRTC技术实现一对一语音通话，WebRTC是一种开放源代码的实时通信技术，可以在浏览器中实现音频和视频通信。使用WebRTC技术，可以在不需要任何插件或软件的情况下，直接在浏览器中进行语音通话。 实现Vue一对一语音通话需要以下步骤： 1. 使用Vue框架搭建前端页面，包括用户登录、呼叫、接听等功能。 2. 使用WebRTC技术实现音频采集、编码、传输和解码等功能。 3. 使用WebSocket或者其他实时通信技术，实现信令传输，包括呼叫请求、接听请求、挂断请求等。 4. 在服务器端实现音频流的转发和处理。 需要注意的是，实现一对一语音通话需要考虑网络延迟、带宽限制、音频质量等问题，需要进行优化和测试。
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值