企业官网建设流程全解析

1. 项目概述：为什么 libswresample 是音视频开发里最常被忽略却最不能出错的“翻译官”

在音视频开发一线干了十多年，我经手过从直播推流 SDK 到离线转码集群、从嵌入式音频处理到 WebAssembly 音频分析的各类项目。每次新人问我：“FFmpeg 里哪个库最容易踩坑？”我几乎不假思索就答——libswresample。不是 libavcodec（编解码器核心），也不是 libavformat（封装格式中枢），而是这个名字里带“resample”、看起来只干“重采样”这一件小事的库。它就像音视频流水线里那个永远穿灰色工装、不说话但每台设备都依赖他校准时间的老师傅：你感觉不到他的存在，直到某天音频突然变调、播放卡顿、左右声道错位，或者导出文件在 iOS 上无声、在安卓上爆音——这时候翻日志，八成会看到一行不起眼的swr_init failed或swr_convert returned -22。

libswresample 的本质，根本不是“重采样”这么简单；它是 FFmpeg 生态中唯一负责跨音频域桥接的实时信号转换引擎。它要同时处理采样率（44.1kHz ↔ 48kHz）、采样格式（S16 ↔ FLTP）、声道布局（stereo ↔ 5.1 ↔ ambisonics）、平面/打包（planar ↔ interleaved）、时间基对齐（AVRational 转换）、缓冲区动态管理（delay compensation）这五大维度的实时映射。而这些维度之间又存在强耦合：比如把 44.1kHz stereo S16 packed 转成 48kHz 5.1 FLTP planar，光是声道重排（channel layout conversion）就要触发内部重采样滤波器重初始化，格式转换又涉及字节序与浮点精度补偿，最后还要把所有帧对齐到新的时间戳基线上——整个过程没有中间状态可存，必须一气呵成。我见过太多团队把 swr_convert 当作“格式转换函数”直接套用，结果在高负载下出现音频撕裂、首帧丢失、内存持续增长，最后排查三天才发现是swr_set_compensation调用时机错了半拍。

它之所以被低估，是因为 FFmpeg 命令行工具（ffmpeg）把它藏得太深：你敲ffmpeg -i in.wav -ar 48000 out.wav，背后全是 libswresample 在干活，但你看不见。一旦你脱离命令行，进入 API 层开发——无论是写一个自定义音频滤镜、对接 WebRTC 的音频前处理模块、还是给 OBS 插件加实时降噪——你就必须亲手初始化 SwrContext、配置 AVChannelLayout、处理输入输出缓冲区对齐、管理延迟补偿窗口。这时候，文档里那句“call swr_init after setting all options”就成了生死线。我带过的三个应届生，在第一个音视频项目里全栽在这句话上：有人设完out_sample_rate就 init，忘了out_ch_layout还是空的；有人用swr_convert_frame却没预分配out_frame->nb_samples，导致内部 realloc 失败；还有人把swr_get_delay(swr, in_sample_rate)算出来的样本数直接当swr_convert的out_count传进去，结果缓冲区溢出——这些都不是编译错误，而是运行时偶发崩溃，日志里只有一串地址，查起来像破案。

所以这篇内容不是教你怎么调用一个函数，而是带你拆开 libswresample 的机箱盖，看清里面齿轮怎么咬合、润滑油该加在哪颗轴承、哪些螺丝拧紧了会卡死、哪些松动了反而更稳。它适合三类人：正在啃 FFmpeg API 文档却卡在 audio resampling 章节的开发者；调试音频同步问题时反复怀疑是时钟源问题、最后发现是 swr 延迟没对齐的工程师；以及准备做跨平台音频处理（尤其涉及 WASM、iOS Core Audio、Android AAudio）需要提前避坑的技术负责人。接下来的内容，全部基于我过去八年在真实项目中踩过的坑、压测过的参数、逆向分析过的 swr 内部状态机，不讲虚的，只说你明天就能用上的东西。

2. 核心设计逻辑：libswresample 不是“转换器”，而是“音频域时空协调员”

2.1 它解决的根本矛盾：硬件采样率刚性 vs 应用场景柔性

先抛开代码，从物理层看一个真实痛点：某款车载信息娱乐系统，主 SoC 的 I2S 接口固定以 44.1kHz 输出音频，但接入的 DSP 芯片只接受 48kHz 流。如果强行用 44.1kHz 数据喂给 48kHz 输入端口，会发生什么？不是简单“变快”或“变慢”，而是每个音频周期的采样点位置发生系统性偏移——44.1kHz 的 1 秒有 44100 个点，48kHz 的 1 秒有 48000 个点，差值 3900 个点。这个偏移会累积成相位失真，低频轰鸣、高频嘶哑，严重时触发 DSP 的抗混叠保护而静音。这就是采样率不匹配引发的时域失配。

libswresample 的核心使命，就是在这个刚性硬件约束和柔性应用需求之间，构建一个可预测、可补偿、可回溯的数学桥梁。它不改变原始信号的频谱本质（不像压缩编码会丢信息），而是通过重采样滤波器组（resampling filter bank）对原始采样点进行插值重建，生成符合目标采样率的新序列。关键在于：这个重建过程必须满足奈奎斯特-香农采样定理——新采样率必须大于原始信号最高频率的两倍，否则会产生混叠（aliasing）。而 libswresample 的默认滤波器（sinc 函数加窗）正是为这个目的设计的：它在频域上是一个带通滤波器，能严格截断高于新采样率一半的所有频率分量，再用 sinc 插值在时域重建。我实测过，当把 44.1kHz 音频升采样到 48kHz 时，若关闭滤波器（swr_set_bool(swr, "filter_size", 0)），高频段（>22.05kHz）会出现明显能量泄露，用频谱分析仪一看，24kHz 附近有尖峰——这就是混叠失真。而默认的 64 抽头 sinc 滤波器能把这部分完全压制在 -96dB 以下，肉耳完全不可辨。

但问题远不止于此。假设你解决了采样率，又来了新挑战：同一段音频，Windows 上播放器默认用 stereo（FL+FR），而你的 VR 应用需要 ambisonics B-format（W+X+Y+Z）四声道。这时 libswresample 要启动第二重能力：声道布局转换（channel layout conversion）。它不是简单复制或丢弃声道，而是根据预定义的声道矩阵（如 Dolby 的 5.1 to stereo downmix matrix）做加权混合。比如把 5.1 的 LFE（低频效果）声道按 0.707 权重加到左、右主声道，同时把 Center 声道按 0.5 权重分配到左右——这个矩阵计算在 swr 内部是固化在swr_build_matrix函数里的，你只需指定in_ch_layout = AV_CH_LAYOUT_5POINT1,out_ch_layout = AV_CH_LAYOUT_STEREO，它自动加载对应矩阵。我曾为某 AR 眼镜项目做空间音频适配，发现官方文档没提一点：当out_ch_layout是AV_CH_LAYOUT_MONO时，libswresample 默认使用L+R 平均法（即(left + right) / 2），但某些专业音频标准要求L+R+Center 加权平均。这时候必须手动调用swr_set_matrix注入自定义矩阵，否则单声道输出会有定位偏差。这个细节，连 FFmpeg 官方测试用例都没覆盖。

2.2 架构分层：从“配置驱动”到“状态机驱动”的演进

libswresample 的 API 设计，清晰反映了其内部架构的演进逻辑。早期版本（<3.0）采用纯配置模式：你设置一堆swr_set_*参数，然后swr_init一次性初始化所有内部状态。这种模式简单，但致命缺陷是无法动态响应运行时变化。比如直播场景中，上游音频源可能突然从 stereo 切到 5.1（因主播开启多麦），如果还用旧的 SwrContext，swr_convert会直接返回错误。

新版本（>=4.0）引入了状态机驱动模型。核心变化是SwrContext内部维护了一个struct ResampleContext状态机，它有三个关键状态：

• SWR_STATE_INITIALIZED：已完成swr_init，但尚未处理任何数据；
• SWR_STATE_RUNNING：已调用swr_convert，内部缓冲区开始积累延迟；
• SWR_STATE_FLUSHING：调用swr_convert传入 NULL 输入帧，触发内部缓冲区清空。

这个状态机决定了你何时能安全修改参数。例如swr_set_compensation（延迟补偿）只能在SWR_STATE_INITIALIZED或SWR_STATE_RUNNING下调用；而swr_set_channel_layout则必须在SWR_STATE_INITIALIZED下调用，否则会触发 assert。我在某次优化直播首帧延迟时，试图在SWR_STATE_RUNNING状态下调用swr_set_compensation补偿网络抖动带来的时钟漂移，结果 swr 直接 abort——因为补偿值变更会强制重置内部滤波器状态，而运行中重置会导致样本计数错乱。正确做法是：先swr_convert(NULL, 0, 0)进入FLUSHING状态清空缓冲，再swr_init重建上下文，最后重新 feed 数据。这个流程看似繁琐，却是保证音频连续性的唯一路径。

更隐蔽的是缓冲区管理策略。libswresample 默认使用双缓冲区环形队列（double-buffered ring buffer）：一个用于接收输入帧（input buffer），一个用于存放转换后输出（output buffer）。swr_convert的工作就是把 input buffer 中的数据经过滤波、重排、格式转换后，填满 output buffer。但 buffer 大小不是固定的——它由out_count参数决定，而out_count又受swr_get_delay返回的内部延迟样本数影响。这里有个经典误区：很多人以为out_count是你要转换的样本数，其实它是你期望输出的最大样本数。swr 会根据当前延迟和输入长度，动态决定实际输出多少。比如swr_get_delay(swr, 44100)返回 1024，表示内部积压了 1024 个样本未输出；此时你传入in_count=2048，swr 实际可能只输出2048 - 1024 = 1024个新样本（补足延迟），剩余 1024 个留在内部缓冲。这个机制保证了输出流的平滑性，但也意味着你必须预留足够大的 output buffer——至少out_count + swr_get_delay()字节。我曾在线上环境遇到过 OOM，查了半天发现是 output buffer 分配太小，swr 在内部 realloc 时失败，但错误码被吞掉了，只留下AVERROR(ENOMEM)的模糊提示。

2.3 为什么它比“自己写重采样”更可靠：滤波器系数的工业级验证

很多团队初期会想：“重采样不就是插值吗？线性插值、三次样条，自己写几十行 C 就搞定。” 我必须坦白：在 2015 年之前，我也这么干过。给一个嵌入式音频设备写轻量级 resampler，用线性插值，资源占用少，CPU 占用低。但上线三个月后，客户投诉“音乐听起来发闷，鼓点没力度”。用 Audacity 打开对比波形，才发现线性插值在高频段引入了严重的相位失真——它把原始正弦波的过零点平移了，导致谐波叠加异常。而 libswresample 的 sinc 滤波器，其系数是经过MATLAB 仿真 + 实测频响验证 + 数百万小时播放压力测试的。它的默认滤波器长度（64）和窗函数（Blackman-Nuttall）组合，在 44.1kHz→48kHz 场景下，能保证通带纹波 < ±0.01dB，阻带衰减 > 120dB，群延迟波动 < 1 sample——这是消费级音频设备的黄金标准。

更关键的是定点数与浮点数的混合精度控制。libswresample 内部对滤波器系数使用 double 精度存储，但计算时可根据swr_set_int_sample_fmt切换为 int32_t 或 float 计算路径。为什么重要？因为 ARM Cortex-A7 上，float 计算比 double 快 3 倍，但 int32_t 的 SIMD 指令（NEON）又能提速 2 倍。swr 会自动选择最优路径：当你设in_sample_fmt = AV_SAMPLE_FMT_S16,out_sample_fmt = AV_SAMPLE_FMT_FLTP，它走 float 路径；若全为 S16，则启用 NEON 的vmlal.s16指令批量计算。这个决策逻辑藏在swri_audio_convert_init函数里，普通用户看不到，但它让同一段代码在树莓派 4 和高通骁龙 8 Gen2 上都能跑出接近理论峰值的性能。我自己做过 benchmark：在 48kHz stereo S16 → 48kHz stereo FLTP 转换中，libswresample 的 NEON 路径比手写的纯 C float 版本快 4.2 倍，且 CPU 占用稳定在 12%，而手写版在高负载下会飙到 28%——因为少了指令流水线优化和缓存预取。

3. 实操核心环节：从零构建一个生产级 SwrContext 初始化流程

3.1 初始化前的“三问”：避免 80% 的初始化失败

在调用swr_alloc_set_opts之前，我强制自己问三个问题。这招是从某次线上事故中学来的：当时一个语音会议 SDK 突然在部分安卓机型上静音，日志显示swr_init failed，但错误码是 -22（EINVAL）。排查两天才发现，是out_ch_layout传了AV_CH_LAYOUT_STEREO，但out_sample_fmt错设为AV_SAMPLE_FMT_S32（32 位整数），而目标设备的音频 HAL 只支持AV_SAMPLE_FMT_S16。swr_init检测到格式不被底层支持，直接返回 EINVAL，但没告诉你具体哪不支持。所以现在，我写初始化函数第一件事就是“三问”：

问 1：输入/输出的采样率、格式、声道布局，是否在目标平台音频子系统的能力范围内？
查方法：Android 用AudioManager.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE)；iOS 用AVAudioSession.currentRoute.outputs.first?.portType+AVAudioSession.sharedInstance().sampleRate；Linux ALSA 用snd_pcm_hw_params_get_rate_min/max。别信文档，实测为准。我记录过某款国产 SoC 的音频驱动，标称支持 44.1kHz，但实测在 44099Hz 时会触发 DMA overrun，必须严格用 44100。

问 2：输入和输出的缓冲区对齐方式，是否匹配？
libswresample 要求输入/输出 frame 的linesize[0]（每行字节数）必须是av_cpu_max_align()（通常是 32）的整数倍。如果不满足，swr_convert会内部 memcpy 对齐，但性能损失高达 30%。正确做法是在av_frame_alloc()后，用av_frame_get_buffer(frame, 32)显式指定对齐值。我见过最惨的案例：某团队用av_frame_alloc()后直接memset分配 data[0]，没考虑对齐，结果在 ARM64 上swr_convert每秒多花 8ms——对实时语音是致命的。

问 3：是否需要启用延迟补偿？补偿窗口大小如何设定？
延迟补偿（compensation）不是可选项，而是实时音频的刚需。swr_set_compensation(swr, delta, 44100)的delta是你要插入或删除的样本数，44100是基准采样率。但delta不能随便设：太大（>1000）会导致音频跳变；太小（<10）则补偿无效。我的经验公式是：delta = (jitter_ms * in_sample_rate) / 1000，其中jitter_ms是网络 RTT 的标准差（从 WebRTC 的RTCPReceiverReport中获取）。比如 RTT jitter 是 15ms，in_sample_rate=48000，则delta = 720。这个值要每 200ms 动态更新一次，而不是初始化时设死。

3.2 完整初始化代码与逐行注释：生产环境验证版

下面是一段我在某跨平台会议 SDK 中使用的初始化代码，已通过 Android/iOS/Windows/macOS 四平台压力测试（1000 小时无崩溃）：

// 初始化 SwrContext 的完整流程（C99 标准） SwrContext* create_swr_context( int in_sample_rate, enum AVSampleFormat in_sample_fmt, const AVChannelLayout* in_ch_layout, int out_sample_rate, enum AVSampleFormat out_sample_fmt, const AVChannelLayout* out_ch_layout, int64_t compensation_delta, // 动态补偿值，单位：样本数 int64_t compensation_base_rate // 补偿基准采样率，通常等于 in_sample_rate ) { SwrContext* swr = NULL; // Step 1: 分配上下文（注意：swr_alloc 已废弃，必须用 swr_alloc_set_opts） // 这里传入 NULL 作为第一个参数，表示创建全新上下文 swr = swr_alloc_set_opts( NULL, // 传 NULL 创建新上下文 out_ch_layout->ch_mask, // 输出声道掩码（AV_CH_LAYOUT_STEREO 等） out_sample_fmt, // 输出采样格式 out_sample_rate, // 输出采样率 in_ch_layout->ch_mask, // 输入声道掩码 in_sample_fmt, // 输入采样格式 in_sample_rate, // 输入采样率 0, // 日志级别，0 表示默认 NULL // 日志回调，NULL 表示用 FFmpeg 默认 ); if (!swr) { av_log(NULL, AV_LOG_ERROR, "swr_alloc_set_opts failed\n"); return NULL; } // Step 2: 强制设置声道布局（AVChannelLayout 结构体，FFmpeg 5.0+ 新标准） // 注意：必须用 av_opt_set_chlayout，不能直接赋值 ch_layout 字段！ if (av_opt_set_chlayout(swr, "out_chlayout", out_ch_layout, 0) < 0 || av_opt_set_chlayout(swr, "in_chlayout", in_ch_layout, 0) < 0) { av_log(NULL, AV_LOG_ERROR, "Failed to set channel layouts\n"); swr_free(&swr); return NULL; } // Step 3: 设置关键性能参数（这些直接影响 CPU 占用和延迟） // filter_size: 滤波器抽头数，默认 64，增大可提升质量但增加 CPU，减小则反之 // 我们在移动设备上设为 32，在桌面端用 64 if (swr_set_int(swr, "filter_size", 32) < 0) { av_log(NULL, AV_LOG_WARNING, "Failed to set filter_size, using default\n"); } // phase_shift: 相位偏移补偿，默认 10，影响瞬态响应 // 对语音通话，设为 0 可减少 pre-echo；对音乐，保持 10 更保真 if (swr_set_int(swr, "phase_shift", 0) < 0) { av_log(NULL, AV_LOG_WARNING, "Failed to set phase_shift\n"); } // dither_method: 抖动算法，防止量化噪声 // 在 S16→S16 转换时必开，否则低电平噪声明显 if (swr_set_int(swr, "dither_method", SWR_DITHER_RECTANGULAR) < 0) { av_log(NULL, AV_LOG_WARNING, "Failed to set dither_method\n"); } // Step 4: 启用延迟补偿（实时音频的生命线） // 注意：swr_set_compensation 必须在 swr_init 之前调用！ if (compensation_delta != 0) { if (swr_set_compensation(swr, compensation_delta, compensation_base_rate) < 0) { av_log(NULL, AV_LOG_WARNING, "Failed to set compensation, ignoring\n"); // 补偿失败不终止，继续初始化 } } // Step 5: 最终初始化（此步会校验所有参数并分配内部缓冲） // 关键：必须检查返回值！swr_init 成功才代表上下文可用 int ret = swr_init(swr); if (ret < 0) { char errbuf[AV_ERROR_MAX_STRING_SIZE]; av_strerror(ret, errbuf, sizeof(errbuf)); av_log(NULL, AV_LOG_ERROR, "swr_init failed: %s (error code %d)\n", errbuf, ret); swr_free(&swr); return NULL; } // Step 6: 验证初始化结果（生产环境必备检查） // 检查内部延迟是否合理（通常应在 100~2000 samples 之间） int64_t delay = swr_get_delay(swr, in_sample_rate); if (delay < 0 || delay > 5000) { av_log(NULL, AV_LOG_ERROR, "Invalid swr delay: %" PRId64 "\n", delay); swr_free(&swr); return NULL; } // 检查输出缓冲区推荐大小（避免后续 malloc 失败） int out_count = swr_get_out_samples(swr, 1024); // 假设输入 1024 样本 if (out_count <= 0) { av_log(NULL, AV_LOG_ERROR, "swr_get_out_samples returned invalid count: %d\n", out_count); swr_free(&swr); return NULL; } av_log(NULL, AV_LOG_INFO, "SwrContext created: in=%dHz/%s/%s -> out=%dHz/%s/%s, delay=%" PRId64 " samples, out_count=%d\n", in_sample_rate, av_get_sample_fmt_name(in_sample_fmt), av_channel_layout_describe(in_ch_layout, NULL, 0), out_sample_rate, av_get_sample_fmt_name(out_sample_fmt), av_channel_layout_describe(out_ch_layout, NULL, 0), delay, out_count); return swr; }

这段代码的关键细节：

• swr_alloc_set_opts的第一个参数传NULL：这是创建全新上下文的唯一正确方式。传非 NULL 会尝试复用已有上下文，但在多线程环境下极易引发竞态。
• av_opt_set_chlayout替代旧版swr_set_channel_layout：FFmpeg 5.0+ 强制使用 AVChannelLayout 结构体，旧 API 已废弃。ch_mask字段只是兼容层，真正生效的是AVChannelLayout的order和map字段。
• swr_set_compensation必须在swr_init前调用：这是硬性规则。我曾为赶工期把这行放到 init 后，结果在高并发下swr_convert随机返回 -22，因为补偿值未被滤波器状态机读取。
• swr_get_out_samples的用途：它不是返回“应该分配多大 buffer”，而是返回“在当前延迟下，输入in_count样本时，最多能输出多少样本”。这个值必须传给av_frame_get_buffer的align参数，确保 buffer 足够。

3.3 动态重配置：如何在不中断音频流的情况下切换参数

真实场景中，参数不可能一成不变。比如 WebRTC 的音频发送端，会根据网络状况动态调整编码码率，进而要求重采样器切换采样率（如从 48kHz 切到 16kHz 以降低带宽）。这时你不能销毁重建 SwrContext——那会导致音频流中断 20~50ms（人耳可感知的“咔哒”声）。正确做法是利用 swr 的状态机，在SWR_STATE_FLUSHING状态下安全重配置：

// 动态重配置 SwrContext（不中断音频流） int swr_reconfigure(SwrContext* swr, int new_in_sample_rate, enum AVSampleFormat new_in_sample_fmt, const AVChannelLayout* new_in_ch_layout, int new_out_sample_rate, enum AVSampleFormat new_out_sample_fmt, const AVChannelLayout* new_out_ch_layout) { // Step 1: 先清空内部缓冲，进入 FLUSHING 状态 // 传入 NULL 输入，0 样本数，触发 flush uint8_t* null_data[AV_NUM_DATA_POINTERS] = {0}; int ret = swr_convert(swr, null_data, 0, NULL, 0); if (ret < 0) { av_log(NULL, AV_LOG_ERROR, "swr_convert flush failed: %d\n", ret); return ret; } // Step 2: 重置所有参数（此时 swr 处于可配置状态） // 注意：必须重设所有参数，包括之前设过的 if (av_opt_set_chlayout(swr, "in_chlayout", new_in_ch_layout, 0) < 0 || av_opt_set_chlayout(swr, "out_chlayout", new_out_ch_layout, 0) < 0) { return AVERROR(EINVAL); } if (swr_set_int(swr, "in_sample_rate", new_in_sample_rate) < 0 || swr_set_int(swr, "out_sample_rate", new_out_sample_rate) < 0 || swr_set_sample_fmt(swr, "in_sample_fmt", new_in_sample_fmt) < 0 || swr_set_sample_fmt(swr, "out_sample_fmt", new_out_sample_fmt) < 0) { return AVERROR(EINVAL); } // Step 3: 重新初始化（此步会重建滤波器，但不丢弃已有状态） ret = swr_init(swr); if (ret < 0) { av_log(NULL, AV_LOG_ERROR, "swr_init after reconfigure failed\n"); return ret; } // Step 4: 验证新配置 int64_t new_delay = swr_get_delay(swr, new_in_sample_rate); if (new_delay < 0) { return AVERROR(EINVAL); } av_log(NULL, AV_LOG_INFO, "SwrContext reconfigured: delay now %" PRId64 "\n", new_delay); return 0; }

这个流程的核心是swr_convert(swr, null_data, 0, NULL, 0)—— 它告诉 swr：“我现在要 flush，请把所有积压样本输出，然后准备好接收新参数”。执行后，swr 内部状态机进入SWR_STATE_FLUSHING，此时调用swr_init会安全地重建所有内部结构，而不会影响正在运行的音频线程。我在某千万级用户语音 App 中用此方案实现了“零感知码率切换”，用户完全感觉不到采样率变化。

4. 常见问题与实战排查：那些文档里绝不会写的“血泪教训”

4.1 经典错误码速查表：从报错到修复的最快路径

提示：av_strerror只能打印错误码字符串，无法定位具体哪行参数错。我的做法是在swr_alloc_set_opts后立即打印所有参数：av_log(..., "in: %dHz %s %s, out: %dHz %s %s", ...)，这样报错时一眼看出是输入还是输出参数异常。

4.2 音频撕裂/跳变的三大隐形元凶与根治方案

元凶 1：swr_get_delay返回值未参与 buffer 分配
现象：音频播放几秒后突然“咔哒”一声，然后恢复正常。
原理：swr_get_delay返回的是内部积压样本数。如果你分配的 output buffer 刚好等于swr_get_out_samples(swr, in_count)，那么当swr_convert需要先输出积压样本时，buffer 就不够了，swr 会 truncate 输出，导致样本丢失。
根治：分配 output buffer 大小 =swr_get_out_samples(swr, in_count) + swr_get_delay(swr, in_sample_rate)。我在某车载系统中，把 buffer 从1024改为1024 + 512（delay=512），撕裂消失。

元凶 2：swr_convert_frame与swr_convert混用
现象：首帧音频丢失，或最后一帧被截断。
原理：swr_convert_frame是高级封装，它会自动管理out_frame->nb_samples，但内部调用的仍是swr_convert。如果你先用swr_convert_frame，再用swr_convert，两个函数对内部状态机的假设不同，导致nb_samples计数错乱。
根治：全程只用一种接口。推荐swr_convert，因为你能完全控制输入输出 buffer，调试日志也更清晰。swr_convert_frame仅适用于快速原型，生产环境禁用。

元凶 3：未处理swr_convert的返回值
现象：音频越来越慢，最终卡死。
原理：swr_convert返回实际转换的样本数。如果返回值小于out_count，说明 swr 内部还有积压，你需要再次调用swr_convert（传入 NULL 输入）来清空。如果忽略返回值，积压会越堆越多，最终swr_get_delay溢出。
根治：必须循环调用直到返回值 ≥out_count，或swr_get_delay≤ 0。我的标准模板：

int converted = 0; while (converted < out_count && swr_get_delay(swr, in_rate) > 0) { int ret = swr_convert(swr, out_data, out_count - converted, in_data, in_count); if (ret < 0) break; converted += ret; in_data = NULL; // 后续调用传 NULL 触发 flush }

4.3 性能瓶颈定位：CPU 占用高的 5 个检查点

当swr_convertCPU 占用飙升，按顺序检查这五点（90% 的问题在此）：

1. **滤波器长度 (filter_size) 是否