基于 Qt6 Multimedia 的实时音频流 RTP 传输系统架构与实现深度研究报告

基于 Qt6 Multimedia 的实时音频流 RTP 传输系统架构与实现深度研究报告

1. 执行摘要

随着网络通信技术的飞速发展，实时音频传输（Real-Time Audio Streaming）已成为现代通信基础设施的核心组成部分，广泛应用于 IP 语音（VoIP）、远程会议及在线教育等领域。本报告旨在针对基于 Qt6 框架的实时音频流传输系统进行详尽的技术分析与架构设计。该系统的核心任务是构建一个双向或单向的音频数据链路，涵盖从声卡采集 Pulse Code Modulation (PCM) 数据、G.711 编码压缩、Real-time Transport Protocol (RTP) 协议封装、User Datagram Protocol (UDP) 网络传输，直至接收端的 RTP 解包、解码、抖动缓冲（Jitter Buffer）管理以及最终通过声卡播放的全过程。

Qt6 Multimedia 模块的引入标志着 Qt 音频架构的重大变革，特别是 QAudioSource 和 QAudioSink 类的引入，取代了 Qt5 中的 QAudioInput 和 QAudioOutput。这一变化不仅涉及 API 的更迭，更深刻影响了底层数据流的处理模式。本报告将深入剖析这些架构变更，并针对实时通信中最为棘手的网络抖动（Jitter）和时钟漂移（Clock Drift）问题，提出基于 QIODevice 子类化的自定义环形缓冲区（Ring Buffer）解决方案。

报告内容基于广泛的技术文档与工程实践，整合了数字信号处理（DSP）理论、网络传输协议规范（RFC 3550）、G.711 编解码标准（ITU-T G.711）以及 Qt6 框架的高级特性，旨在为系统架构师与嵌入式软件工程师提供一份具备高度实操价值与理论深度的技术指南。

—

2. 引言与技术背景

2.1 实时音频通信的演进与挑战

实时音频通信（RTC）与传统的文件播放有着本质的区别。在文件播放场景下，系统可以预先缓冲大量数据（数秒甚至数分钟），从而完全屏蔽网络波动的影响。然而，在 VoIP 等实时场景中，交互的即时性要求端到端延迟（End-to-End Latency）必须控制在极低范围内。根据国际电信联盟（ITU）的建议，高质量语音通话的单向延迟应低于 150 毫秒。一旦超过此阈值，用户将明显感知到通话迟滞，甚至出现“对讲机效应”，严重影响沟通体验。

在基于分组交换（Packet Switched）的 IP 网络上实现低延迟传输面临着诸多挑战：

1. 网络抖动（Jitter）：数据包到达接收端的时间间隔不均匀，导致音频播放出现断续或快进现象。
2. 丢包（Packet Loss）：UDP 协议不保证可靠传输，丢包会导致音频信号缺失，产生爆破音或静音。
3. 时钟不同步（Clock Drift）：发送端与接收端的采样时钟频率存在微小偏差（例如发送端 8000.1Hz，接收端 7999.9Hz），长期运行会导致缓冲区溢出或欠载。

2.2 Qt6 Multimedia 架构变革

Qt6 Multimedia 模块经历了一次彻底的重构。Qt 公司移除了对后端插件系统的依赖，转而直接调用操作系统的底层多媒体 API（如 Windows 的 WASAPI、macOS 的 AVFoundation、Linux 的 GStreamer/PulseAudio）1。

核心类变更对比：

这一变革要求开发者在实现网络流媒体时，必须重新设计数据管道（Pipeline）。特别是在接收端，QAudioSink 默认行为是从一个 QIODevice 中“拉取”数据，而网络数据是异步“推送”到达的。这种 Push-Pull 模型的不匹配（Impedance Mismatch）是实现 Qt6 实时音频流的最大工程难点，必须通过自定义的缓冲机制加以解决。

—

3. 数字音频理论基础与编码标准

3.1 PCM 脉冲编码调制

脉冲编码调制（PCM）是模拟信号数字化的基石。它通过采样（Sampling）、量化（Quantization）和编码三个步骤将连续的模拟波形转换为离散的数字序列。

• 采样率（Sampling Rate）：根据奈奎斯特-香农采样定理，为了无损还原频率为f m a x f_{max}fmax​的模拟信号，采样率f s f_sfs​必须满足f s ≥ 2 f m a x f_s \ge 2f_{max}fs​≥2fmax​。人类语音的有效频率范围通常在 300Hz 至 3400Hz 之间，因此电信领域通用的采样率为 8000Hz（8kHz）。

• 位深度（Bit Depth）：决定了信号的动态范围（Dynamic Range）。16位有符号整数（Signed 16-bit Integer）提供约 96dB 的动态范围，足以覆盖高保真语音需求。

• 码率计算： 对于 8kHz 采样、16位深度、单声道的 PCM 信号，其原始码率为：

  Bitrate = 8000 × 16 × 1 = 128 , 000 bps = 128 kbps \text{Bitrate} = 8000 \times 16 \times 1 = 128,000 \text{ bps} = 128 \text{ kbps}Bitrate=8000×16×1=128,000bps=128kbps

3.2 G.711 压缩算法（PCMA 与 PCMU）

虽然 128 kbps 在局域网内可以接受，但在广域网传输中，为了节省带宽并减少 IP 分片风险，通常采用 G.711 标准进行压缩。G.711 是一种非线性压扩（Companding）算法，将 13 位或 14 位的线性 PCM 样本压缩为 8 位，从而将码率降低至 64 kbps。

3.2.1 算法原理

G.711 利用了人耳的听觉特性：人耳对低音量信号的灵敏度远高于高音量信号。因此，算法采用对数曲线对信号进行量化，在低电平区域分配更多的量化级数，而在高电平区域分配较少。

• A-law (PCMA)：主要用于欧洲及世界大部分地区。其动态范围稍小，但在低信噪比下表现更优。
• μ \muμ-law (PCMU)：主要用于北美和日本。其动态范围略大，但在小信号处的量化噪声稍大。

3.2.2 转换实现机制

G.711 的实现极其高效，通常通过查表法（Look-up Table）或简单的位运算实现，无需复杂的浮点运算或历史状态依赖（Stateless），这使得它非常适合嵌入式和实时应用。

m u \\mumu-law 编码过程（简化）：

1. 取 14 位线性样本的补码。
2. 若为负数，取反并记录符号位。
3. 加上偏置值 33（二进制 100001）。
4. 根据数值大小确定段号（Segment）和段内位置。
5. 拼接符号位、段号和段内位，最后对所有位取反（为了增加线路上的信号密度）。

该过程保证了极低的算法延迟（Algorithmic Delay），通常被认为是零延迟编码，这对于实时通信至关重要。

—

4. 网络传输协议分析：RTP 与 UDP

在传输层和应用层之间，实时音频流通常采用 RTP（实时传输协议）承载于 UDP 之上。

4.1 UDP 的必要性

传输控制协议（TCP）虽然提供可靠传输，但在实时音频场景下往往被视为不可用。TCP 的重传机制（Retransmission）会导致不可预测的延迟。当一个数据包丢失时，TCP 协议栈会阻塞后续数据的交付，直到丢失的数据包重传成功。这种“队头阻塞”（Head-of-Line Blocking）会导致音频流长时间停顿，随后的快速播放又会破坏时间结构。相比之下，UDP 允许丢包，接收端可以通过丢包隐藏（Packet Loss Concealment, PLC）技术补救，从而维持通话的实时性。

4.2 RTP 协议详解 (RFC 3550)

RTP 协议为 UDP 数据包补充了实时传输所需的元数据，主要包括序列号、时间戳和同步源标识符。

RTP 数据包头结构（12 字节）：

时间戳计算实例：
假设打包时长为 20ms（VoIP 标准时长），采样率为 8000Hz。
每个数据包包含的样本数= 8000 × 0.02 = 160 = 8000 \times 0.02 = 160=8000×0.02=160个样本。
因此，每发送一个数据包，RTP 头中的 Timestamp 字段应增加 160，而无论实际的字节载荷是多少（即使经过 G.711 压缩，代表的时间跨度依然是 160 个采样周期）。

4.3 网络字节序 (Endianness)

网络协议标准采用大端序（Big Endian），而现代大多数 CPU（x86, ARM）采用小端序（Little Endian）。在构建 RTP 头时，必须显式进行字节序转换。Qt 提供了 QDataStream 类，通过 stream.setByteOrder(QDataStream::BigEndian) 可以方便地处理这一问题，避免手动调用 htons 或 htonl 带来的代码可读性下降。

—

5. Qt6 发送端架构与实现 (Transmitter)

发送端的核心职责是从声卡采集 PCM 数据，进行可选的 G.711 编码，封装 RTP 头，并通过 UDP 发送。

5.1 音频采集配置 (QAudioSource)

首先，需要配置 QAudioFormat 并选择合适的输入设备。

// 音频格式配置：8kHz, 单声道, 16位小端序整型QAudioFormat format;format.setSampleRate(8000);format.setChannelCount(1);format.setSampleFormat(QAudioFormat::Int16);// Qt6 中明确指定为 Int16// 获取默认输入设备QAudioDevice inputDevice=QMediaDevices::defaultAudioInput();if(!inputDevice.isFormatSupported(format)){qWarning()<<"默认设备不支持该格式，尝试匹配最近似格式...";format=inputDevice.nearestFormat(format);}// 创建 QAudioSource 实例QAudioSource*audioSource=newQAudioSource(inputDevice,format,this);

5.2 数据读取模式：Push vs Pull

QAudioSource 提供了两种启动模式：

1. Push 模式：start(QIODevice *dest)。音频数据直接写入指定的目标设备（如文件或套接字）。
2. Pull 模式：start() 返回一个指向内部缓冲区的 QIODevice*。用户通过连接 readyRead 信号手动读取数据。

对于 RTP 传输，Pull 模式 是必选方案。
原因在于 RTP 传输需要固定时长的音频帧（例如 20ms）。如果使用 Push 模式直接写入 UDP 套接字，开发者将无法控制每次写入的数据块大小，也无法在数据前插入 RTP 头。通过 Pull 模式，我们可以在 readyRead 槽函数中精确读取固定字节数（例如 320 字节对应 20ms 的 16位 PCM），从而实现精确的帧封装。

5.3 发送端核心逻辑实现

以下代码展示了如何处理音频数据并封装 RTP 包：

// AudioSender.hclassAudioSender:publicQObject{Q_OBJECTpublic:explicitAudioSender(QObject*parent=nullptr);voidstartStreaming(constQHostAddress&destAddr,quint16 port);privateslots:voidonAudioReady();private:QAudioSource*m_audioSource;QIODevice*m_inputDevice;// 用于读取原始 PCMQUdpSocket*m_udpSocket;QHostAddress m_destAddr;quint16 m_destPort;// RTP 状态变量quint16 m_sequenceNumber;quint32 m_timestamp;quint32 m_ssrc;};// AudioSender.cppvoidAudioSender::onAudioReady(){// 目标帧大小：20ms @ 8kHz, 16-bit = 160 samples * 2 bytes = 320 bytes// 详细的计算与控制策略见 5.4 节constqint64 frameSize=320;// 循环读取缓冲区中所有完整的帧// “凑够一帧发一帧”，不足一帧则等待下次 readyReadwhile(m_inputDevice&&m_inputDevice->bytesAvailable()>=frameSize){QByteArray pcmData=m_inputDevice->read(frameSize);// 步骤 1: G.711 编码 (可选)// QByteArray encodedData = G711::encode(pcmData);// 若启用编码，payloadSize 将变为 160 字节，但代表的时长仍为 20msQByteArray payload=pcmData;// 这里演示传输原始 L16 音频// 步骤 2: 构建 RTP 包QByteArray rtpPacket;QDataStreamstream(&rtpPacket,QIODevice::WriteOnly);stream.setByteOrder(QDataStream::BigEndian);// 关键：大端序// 构造 RTP 头quint8 v_p_x_cc=0x80;// Version 2quint8 m_pt=96;// Payload Type 96 (Dynamic for L16) 或 0 (PCMU)stream<<v_p_x_cc<<m_pt<<m_sequenceNumber<<m_timestamp<<m_ssrc;// 写入载荷stream.writeRawData(payload.constData(),payload.size());// 步骤 3: UDP 发送m_udpSocket->writeDatagram(rtpPacket,m_destAddr,m_destPort);// 步骤 4: 更新状态m_sequenceNumber++;m_timestamp+=160;// 无论是否压缩，时间戳增量严格对应采样数 (20ms * 8000Hz)}}

5.4 精确包长控制与时间戳同步 (Precise Frame Control)

在 VoIP 行业标准中，推荐的打包时长（Packetization Time, ptime）通常为 10ms、20ms 或 30ms 。精确控制这一参数对于减少网络开销和降低延迟至关重要。

5.4.1 目标字节数计算 (Target Byte Count)

首先，必须根据音频格式精确计算目标时长的字节数。公式为：

Bytes = SampleRate × BytesPerSample × Channels × Duration(s) \text{Bytes} = \text{SampleRate} \times \text{BytesPerSample} \times \text{Channels} \times \text{Duration(s)}Bytes=SampleRate×BytesPerSample×Channels×Duration(s)
以标准的8000Hz, 16-bit (2 Bytes), 单声道音频为例：

5.4.2 数据驱动切片策略 (Data-Driven Slicing)

Qt 的 readyRead 信号触发是不确定的（可能一次通知 100 字节，也可能 500 字节）。为了保证发送出的 RTP 包严格符合上述时长，绝不能依赖定时器（Timer）去读取。

正确的做法是在 readyRead 槽函数中采用“凑够切片”的逻辑：

1. 循环检测：使用 while (bytesAvailable() >= TARGET_SIZE) 循环。
2. 原子读取：只有当缓冲区数据量足够一个完整帧时，才调用 read(TARGET_SIZE)。
3. 剩余保留：如果缓冲区剩余数据不足一帧（例如剩下 100 字节，而目标是 320 字节），则退出循环，让数据留在缓冲区中，等待下一次 readyRead 信号补齐 。

5.4.3 降低内部缓冲延迟 (Latency Configuration)

默认情况下，操作系统的音频驱动可能会缓存较多数据（如 200ms）才通知应用层一次，这会造成突发发送（Burst）。为了平滑发送，应设置 QAudioSource 的内部缓冲区大小：

// 建议设置为 2~3 个包的大小。例如 20ms 包 (320 bytes) -> 设为 640~1280 字节// 设置过小会导致系统调度来不及处理而丢数据，设置过大会增加延迟m_audioSource->setBufferSize(1280);

注：此设置在不同平台（Windows/Linux/macOS）表现可能不同，需根据实际测试微调。

5.4.4 时间戳同步规则

无论数据是否经过 G.711 压缩，RTP 头部的 timestamp 增量必须始终对应原始采样点数。

• 错误做法：根据压缩后的字节数增加时间戳（例如 G.711 20ms 包只有 160 字节，时间戳加 160，这是巧合，如果是 L16 格式则是 320 字节，时间戳依然加 160）。
• 正确做法：CurrentTimestamp += SampleRate * Duration_in_Seconds。

—

6. Qt6 接收端架构与抖动缓冲 (Receiver & Jitter Buffer)

接收端的实现远比发送端复杂。直接将 QUdpSocket 接收的数据写入 QAudioSink 是不可行的，原因如下：

1. Push 与 Pull 的冲突：QUdpSocket 是事件驱动的（Push），当数据到达时触发信号；QAudioSink 是主动拉取的（Pull），按照硬件时钟频率请求数据。
2. 网络抖动：UDP 数据包的到达间隔是不均匀的。如果网络延迟导致数据包晚到 10ms，QAudioSink 可能会因为无数据可读而发生“欠载”（Underrun），导致音频输出停止或产生爆音。

因此，必须实现一个抖动缓冲区（Jitter Buffer）。在 Qt 架构中，最优雅的实现方式是继承 QIODevice 类，创建一个自定义的环形缓冲区。

6.1 抖动缓冲区的理论模型

抖动缓冲区的本质是一个队列，用于平滑网络数据到达速率与音频播放速率之间的差异。

• 写入端（网络线程）：按照不规则的时间间隔写入数据块。
• 读取端（音频线程）：按照规则的时间间隔（由采样率决定）读取数据块。
• 缓冲深度（Target Delay）：缓冲区必须维持一定量的数据（例如 60ms），以抵消网络传输中的最大延迟波动。

6.2 自定义 QIODevice 实现环形缓冲

我们需要实现一个线程安全的环形缓冲区类 JitterBuffer，继承自 QIODevice。

6.2.1 环形缓冲数据结构设计

为了避免频繁的内存分配与释放（malloc/free），环形缓冲区应使用预分配的固定大小内存块（例如 64KB）。

// JitterBuffer.h#include<QIODevice>#include<QMutex>#include<QByteArray>#include<QWaitCondition>classJitterBuffer:publicQIODevice{Q_OBJECTpublic:explicitJitterBuffer(QObject*parent=nullptr);// 供 QUdpSocket 调用的写入接口voidwriteAudioData(constQByteArray&data);// 设置缓冲阈值（例如 60ms 对应的数据量）voidsetThreshold(intbytes);protected:// QIODevice 必须实现的虚函数qint64readData(char*data,qint64 maxlen)override;qint64writeData(constchar*data,qint64 len)override;qint64bytesAvailable()constoverride;private:QByteArray m_buffer;// 物理存储intm_head;// 写入指针intm_tail;// 读取指针intm_count;// 当前有效字节数intm_bufferSize;// 缓冲区总容量intm_prefetchThreshold;// 预缓冲阈值boolm_isBuffering;// 是否处于缓冲状态QMutex m_mutex;// 线程锁};

6.2.2 核心逻辑实现

实现中的关键点在于处理环形回绕（Wrap-around）以及线程同步。

// JitterBuffer.cppJitterBuffer::JitterBuffer(QObject*parent):QIODevice(parent){m_bufferSize=65536;// 64KB，约 4 秒音频m_buffer.resize(m_bufferSize);m_head=0;m_tail=0;m_count=0;m_prefetchThreshold=960;// 60ms @ 16-bit 8kHzm_isBuffering=true;setOpenMode(QIODevice::ReadOnly);// 对外表现为只读设备（供 AudioSink 用）}voidJitterBuffer::writeAudioData(constQByteArray&data){QMutexLockerlocker(&m_mutex);constchar*src=data.constData();intlen=data.size();// 简单的溢出处理：如果空间不足，丢弃旧数据（移动 tail）if(m_count+len>m_bufferSize){intdrop=(m_count+len)-m_bufferSize;m_tail=(m_tail+drop)%m_bufferSize;m_count-=drop;// 在实际应用中，这里应该记录日志或进行更平滑的处理}// 分段写入环形缓冲intchunk1=qMin(len,m_bufferSize-m_head);memcpy(m_buffer.data()+m_head,src,chunk1);m_head=(m_head+chunk1)%m_bufferSize;if(len>chunk1){memcpy(m_buffer.data()+m_head,src+chunk1,len-chunk1);m_head=(m_head+(len-chunk1))%m_bufferSize;}m_count+=len;// 通知 QIODevice 有数据可读emitreadyRead();}qint64JitterBuffer::readData(char*data,qint64 maxlen){QMutexLockerlocker(&m_mutex);// 缓冲策略：如果处于缓冲状态且数据不足，返回静音（或 0）if(m_isBuffering){if(m_count<m_prefetchThreshold){memset(data,0,maxlen);// 输出静音returnmaxlen;}m_isBuffering=false;// 达到阈值，开始播放}qint64 bytesToRead=qMin((qint64)m_count,maxlen);// 分段读取intchunk1=qMin((int)bytesToRead,m_bufferSize-m_tail);memcpy(data,m_buffer.constData()+m_tail,chunk1);m_tail=(m_tail+chunk1)%m_bufferSize;if(bytesToRead>chunk1){memcpy(data,m_buffer.constData()+m_tail,chunk1,bytesToRead-chunk1);m_tail=(m_tail+(bytesToRead-chunk1))%m_bufferSize;}m_count-=bytesToRead;// 欠载检测：如果数据读空了，重新进入缓冲状态if(m_count==0){m_isBuffering=true;}// 填充剩余请求的长度为静音，防止 AudioSink 饥饿if(bytesToRead<maxlen){memset(data+bytesToRead,0,maxlen-bytesToRead);returnmaxlen;}returnbytesToRead;}qint64JitterBuffer::bytesAvailable()const{QMutexLockerlocker(&m_mutex);// 必须加上 QIODevice 基类的 buffer 大小（虽然我们禁用了基类 buffer）returnm_count+QIODevice::bytesAvailable();}

6.3 接收端主逻辑集成

接收端主要负责监听 UDP 端口，解包 RTP，并将载荷写入 JitterBuffer。

voidAudioReceiver::init(){// 1. 网络初始化m_udpSocket=newQUdpSocket(this);m_udpSocket->bind(QHostAddress::Any,1234,QUdpSocket::ShareAddress);connect(m_udpSocket,&QUdpSocket::readyRead,this,&AudioReceiver::processUdpDatagrams);// 2. 缓冲初始化m_jitterBuffer=newJitterBuffer(this);// 3. 音频输出初始化QAudioFormat format;//... 设置与发送端一致的格式...QAudioDevice outputDevice=QMediaDevices::defaultAudioOutput();m_audioSink=newQAudioSink(outputDevice,format,this);// 4. 启动播放：Sink 从 Buffer 拉取数据m_audioSink->start(m_jitterBuffer);}voidAudioReceiver::processUdpDatagrams(){while(m_udpSocket->hasPendingDatagrams()){QNetworkDatagram datagram=m_udpSocket->receiveDatagram();QByteArray packet=datagram.data();// RTP 最小头长度检查if(packet.size()<=12)continue;// 剥离 RTP 头 (前12字节)// 实际工程中应在此处检查 Sequence Number 进行丢包统计和乱序重排QByteArray payload=packet.mid(12);// G.711 解码 (如果发送端进行了编码)// QByteArray pcm = G711::decode(payload);QByteArray pcm=payload;// 假设为 L16// 写入抖动缓冲m_jitterBuffer->writeAudioData(pcm);}}

—

7. 深入议题：时钟漂移与自适应缓冲

7.1 时钟漂移现象 (Clock Drift)

在两个独立的硬件设备之间，晶振频率永远不可能完全一致。

• 发送端快（8001Hz），接收端慢（7999Hz）：接收端的缓冲区会逐渐填满，最终导致溢出，延迟无限增大。
• 发送端慢，接收端快：接收端的缓冲区会频繁欠载，导致声音断断续续。

7.2 解决方案

在专业级实现中，JitterBuffer 不应仅是一个被动的队列，而应具备自适应能力。

1. 动态重采样（Resampling）：如果检测到 m_count 持续增加，说明接收端播放太慢。可以调用重采样算法（如 libsamplerate），将 160 个样本“压缩”为 159 个样本输出，从而加快消耗速度。反之亦然。
2. 静音压缩与插入：利用语音活动检测（VAD），在静音期调整缓冲区水位。
3. 简单策略（适合本报告场景）：监控水位。当水位过高（如 > 200ms）时，直接丢弃最旧的数据包（快速追赶）；当水位过低时，插入舒适噪音（Comfort Noise）或重复上一帧（PLC）。

—

8. 总结与展望

本报告详细阐述了基于 Qt6 Multimedia 模块构建实时 RTP 音频传输系统的完整技术路径。通过对比 Qt5 与 Qt6 的架构差异，明确了 QAudioSource（Pull 模式）与 QAudioSink（Pull 模式）在网络流媒体场景下的最佳实践。

核心结论：

1. 架构适配：必须使用 QIODevice 子类化的方式来实现抖动缓冲区，作为连接异步 UDP 网络层与同步音频播放层的桥梁。
2. 精确控制：发送端必须通过计算目标字节数并在 readyRead 中使用循环切片逻辑，才能保证 RTP 包严格对应 10ms/20ms/30ms 的时长。
3. 协议规范：严格遵循 RTP 协议标准（大端序、时间戳机制）是保证系统互操作性的关键。
4. 缓冲策略：环形缓冲区的实现必须是线程安全的，且具备预缓冲（Prefetching）机制以防止启动时的瞬间欠载。

通过上述设计，开发者可以在 Qt6 跨平台框架下实现低延迟（< 150ms）、高稳定性的实时语音通信功能。未来的优化方向可以包括集成 WebRTC 的回声消除（AEC）模块以及基于 Opus 编码器的动态码率适应，以进一步提升复杂网络环境下的通话质量。

引用的著作

1. Qt Multimedia in Qt 6, 访问时间为 十二月 15, 2025， https://www.qt.io/blog/qt-multimedia-in-qt-6
2. 7.4 Protocols for Real-Time Interactive Applications - gaia, 访问时间为 十二月 15, 2025， https://gaia.cs.umass.edu/kurose_ross/retired/protocols_real_time_interactive.pdf
3. Configuring the Jitter Buffer - Tieline, 访问时间为 十二月 15, 2025， http://www.tieline.com/manuals/TLR5200D/en/v2_14/programming_the_jitter_buffer.htm
4. What is Jitter and How to use Jitter Buffer to reduce jitter? - Tencent RTC, 访问时间为 十二月 15, 2025， https://trtc.io/blog/details/Jitter-and-Jitter-Buffer
5. Real-time Transport Protocol - Wikipedia, 访问时间为 十二月 15, 2025， https://en.wikipedia.org/wiki/Real-time_Transport_Protocol
6. QAudioSource Class | Qt Multimedia | Qt 6.10.1, 访问时间为 十二月 15, 2025， https://doc.qt.io/qt-6/qaudiosource.html
7. QAudioSink Class - Qt - Developpez.com, 访问时间为 十二月 15, 2025， https://qt.developpez.com/doc/6.5/qaudiosink/
8. G.711 - Wikipedia, 访问时间为 十二月 15, 2025， https://en.wikipedia.org/wiki/G.711
9. 6.4 RTP - IC/UFF, 访问时间为 十二月 15, 2025， http://www2.ic.uff.br/~michael/kr1999/6-multimedia/6_04-rtp.htm
10. Real Time Transport Protocol (RTP) - GeeksforGeeks, 访问时间为 十二月 15, 2025， https://www.geeksforgeeks.org/computer-networks/real-time-transport-protocol-rtp/
11. Introducing RTP: The Packet Format - Webex Blog, 访问时间为 十二月 15, 2025， https://blog.webex.com/engineering/introducing-rtp-the-packet-format/
12. How to calculate the RTP Timestamp for each packet in an audio stream - Stack Overflow, 访问时间为 十二月 15, 2025， https://stackoverflow.com/questions/24658525/how-to-calculate-the-rtp-timestamp-for-each-packet-in-an-audio-stream
13. RTP Timestamp Calculation - LM Tools, 访问时间为 十二月 15, 2025， https://lmtools.com/content/rtp-timestamp-calculation
14. QDataStream Class Reference, 访问时间为 十二月 15, 2025， https://internal.dunescience.org/doxygen/classQDataStream.html
15. Question regarding Big/Little endian | Qt Forum, 访问时间为 十二月 15, 2025， https://forum.qt.io/topic/71544/question-regarding-big-little-endian
16. Play audio data using QIODevice (Qt4.6 with VC++) - Stack Overflow, 访问时间为 十二月 15, 2025， https://stackoverflow.com/questions/3426868/play-audio-data-using-qiodevice-qt4-6-with-vc
17. QIODevice Class | Qt Core | Qt Documentation (Pro) - Felgo, 访问时间为 十二月 15, 2025， https://felgo.com/doc/qt/qiodevice/
18. Ring Buffers | Switchboard Documentation, 访问时间为 十二月 15, 2025， https://docs.switchboard.audio/ring-buffers/
19. Creating a Circular Buffer in C and C++ - Embedded Artistry, 访问时间为 十二月 15, 2025， https://embeddedartistry.com/blog/2017/05/17/creating-a-circular-buffer-in-c-and-c/
20. adaptive jitter buffer without packet loss - Stack Overflow, 访问时间为 十二月 15, 2025， https://stackoverflow.com/questions/27079064/adaptive-jitter-buffer-without-packet-loss
    $$