简介面向C#/.NET开发者的NAudio音频处理示例包聚焦录音、播放与实时音频波形图绘制可用于录音软件、语音剪辑、音频实时监测等工具开发非常适合初中级程序员参考学习。与常规从声卡设备直接获取波形的做法不同项目演示从音频流字节数据中提取样本并绘制图形思路更贴近实际文件与流式处理场景也更容易迁移到其他音频处理任务。压缩包共171个文件以cs源码、xaml界面、dll依赖库及wav测试音频为主另含WPF编译资源与缓存文件整体体积仅3.01MB项目包含解决方案文件便于在Visual Studio中直接打开浏览。目前已有6474人浏览学习采用WPF框架内置PolylineWaveFormControl等波形控件可快速体验录音、播放与波形显示联动同时涉及WaveInEvent/WaveOutEvent调用、样本归一化、缓冲区更新及UI线程协调等关键细节能帮助读者掌握NAudio常用API与实时绘制管线并在此基础上扩展频谱分析、音量计等功能。1. 项目定位为什么录音/播放要和波形绘制放在一起做做音频处理的人应该都有同感录音和波形可视化是一对天生的搭档。不管是做录音笔、语音识别前端、音频剪辑工具还是做上位机里的语音提示反馈模块用户都希望看得到声音。声音是看不见摸不着的波形图就是那个唯一直观的反馈窗口。这个项目用 C# NAudio 实现了三条核心链路录音写 WAV 文件、播放 WAV 文件、实时绘制波形图。乍一看稀松平常但有一个值得注意的技术选型波形图的数据是从音频流里取的而不是从声卡设备里单独捕获的。这个细节决定了整个架构的走向。如果你做过类似的开发应该能立刻理解这里面的差别。从设备捕获比如用 WaveInEvent 单独开一路采集要走额外的设备通道要做时钟对齐、数据同步很容易出现录出来的文件和显示的波形对不上的尴尬情况。而从音频流里直接抽数据录下来的每一帧都同时被写入文件和波形绘制模块天然就是同步的。这个思路在后面我会详细展开。顺便说一下这个项目适合谁参考用过 NAudio 但没做过可视化的人、正在做录音上位机却卡在 UI 刷新上的人、以及准备做音频编辑器想做波形预览的人。如果你的场景还包括播放时的实时频谱或示波器效果这篇文章的思路同样能迁移过去。2. 整体架构从简陋到可用我踩过的两个坑2.1 第一版方案先录制再画整条波形结果发现完全不对我先说下最初的设计思路这也是很多新手最容易掉进去的坑。第一版我用最简单粗暴的方式调用 NAudio 的 WaveFileWriter 录完整个 WAV 文件后再一次性读取整个文件的字节数组计算所有采样点的峰值然后在 PictureBox 上画出完整的静态波形。这样做有两点问题录制过程中用户完全看不到波形反馈体验很差。对于录音类工具比如会议记录、语音质检用户需要在录的时候就确认刚才那句话到底录进去没有而不是等停下来了才知道。如果文件很大一次性读入内存解析所有采样点内存占用高绘制的坐标计算也麻烦还需要处理缩放和平移。所以第一版很快就被我否了。实时性是这个项目的核心卖点没有实时波形录音体验就打折扣。2.2 第二版方案从音频流抽数据文件既用于存储也用于可视化第二版才是我觉得值得分享的方案。整个架构分三层采集层WaveInEvent 负责从麦克风采集 PCM 数据16bit单声道44100Hz。数据分发层在 DataAvailable 事件中把缓冲区的字节数组同时交给两个模块——WAV 文件写入器和波形绘制模块。回放层用 WaveOutEvent 播放 WAV 文件播放时也通过一个自定义的 SampleProvider 从音频流中抽取数据来绘制播放中的波形。注意第二层的设计波形数据源是录音事件里的字节数组而不是设备端二次获取。这样做的好处是文件里写的和屏幕上画的严格来自同一份数据不存在时间偏移。代码链路短不需要额外的设备捕获线程CPU 占用低。波形数据本质上就是音频流数据的副产品不需要复制一份临时文件。这个架构说白了就一句话让数据流经过一个管道管道中间开一个阀门接出来用于可视化主路径不变。这样不管后面是加密写入、网络传输还是本地保存波形模块都可以无感接入。2.3 为什么选择 NAudio 而不是其他库有人可能会问C# 做音频为什么不用 WinMM、WPF MediaKit 或者 CSCoreWinMM 是底层 C API直接 P/Invoke 太痛苦而且需要自己管理缓冲区。WPF MediaKit 偏视频对音频流可视化支持弱。CSCore 虽然也是封装好的库但它的生态、文档和社区活跃度都不如 NAudio。NAudio 的优势在于它把设备枚举、采集、播放、音频格式转换、流处理全部封装成了易于组合的类尤其是 ISampleProvider 这个接口做中间件和可视化非常顺手。如果你做 Web 开发、上位机、中小型工具NAudio 是一个可靠的选择MIT 协议商用也没有后顾之忧。3. 录音到绘制的核心链路拆解3.1 WaveInEvent 采集参数怎么定先看录音模块的初始化代码这是整个项目的起点private WaveInEvent waveIn; private WaveFileWriter waveWriter; private void StartRecording(string filePath) { waveIn new WaveInEvent { DeviceNumber 0, WaveFormat new WaveFormat(44100, 16, 1), BufferMilliseconds 50 }; waveIn.DataAvailable OnDataAvailable; waveIn.RecordingStopped OnRecordingStopped; waveWriter new WaveFileWriter(filePath, waveIn.WaveFormat); waveIn.StartRecording(); } private void OnDataAvailable(object sender, WaveInEventArgs e) { // e.Buffer 是采集到的 PCM 字节数组 // e.BytesRecorded 是本次有效字节数 // 第一路写入 WAV 文件 waveWriter.Write(e.Buffer, 0, e.BytesRecorded); // 第二路将同一份数据交给波形模块 DrawWaveFromPcmBytes(e.Buffer, e.BytesRecorded); }几个参数值得注意44100Hz、16bit、单声道是语音类应用最常见的 PCM 配置WAV 文件头也容易解析。如果是做 MP3 预处理建议用双声道但要注意左右声道交织的处理。BufferMilliseconds 50表示每 50ms 触发一次 DataAvailable。这个值不宜设太小比如 10ms否则事件触发的频率太高UI 刷新跟不上也不宜设太大否则实时性变差用户会觉得波形卡顿。50ms 是我实际测试下来比较均衡的值。如果设备不支持 44100HzNAudio 的 WaveInEvent 会抛异常。正式项目中一般先枚举所有输入设备再选择支持目标格式的设备。3.2 从字节数组到波形点PCM 数据怎么解析这里的核心鞋子是把 PCM 的二进制字节还原成采样值并映射到画布高度上。针对 16bit 单声道每个采样点占 2 个字节小端序存储。假设音频流用 short 表示那么从字节数组还原采样值的代码如下private short[] ConvertBytesToSamples(byte[] buffer, int byteCount) { int sampleCount byteCount / 2; short[] samples new short[sampleCount]; for (int i 0; i sampleCount; i) { // 小端序低字节在前高字节在后 samples[i] (short)(buffer[i * 2] | (buffer[i * 2 1] 8)); } return samples; }如果你用的不是 16bit 而是 32bit floatNAudio 内部很多场景是 float代码会稍有不同但只要拿到采样值后续的归一化逻辑就一样了。采样的范围是 -32768 到 32767我们需要把幅度映射到控件的高度上比如 PictureBox 高度是 200 像素主播区 40px 到 160px那么横线是 100px 处采样值 0 对应 100px32767 对应 40px-32768 对应 160px。3.3 500ms 刷新策略避免 UI 卡死这里有一个最容易踩的坑在 DataAvailable 事件里直接画 UI。DataAvailable 的触发频率如果是 20 次/秒50ms 一次直接在这个回调里调用 PictureBox.Invalidate() 的问题是——它不一定在 UI 线程执行。简单来说WinForms 的控件事件处理器必须从 UI 线程调用而 DataAvailable 跑在 NAudio 的录音线程池中。如果直接访问 control 的属性和方法轻则报跨线程访问异常重则画面闪烁甚至卡死。我的经验是两步走用一个线程安全的队列暂存最近若干毫秒的采样数据。用 WinForms 的TimerInterval100ms轮询队列取出数据后在 UI 线程里绘制。Timer 是 WinForms 控件自带的保证回调在 UI 线程同步执行。100ms 刷新一次波形人眼看起来是连续的CPU 占用也低。如果刷新间隔小于 30msUI 反而会开始闪烁没必要。private void timerWave_Tick(object sender, EventArgs e) { // 从队列取数据、计算峰值、画波形 }4. 播放音频文件的同时抽取波形数据4.1 用自定义 SampleProvider 截取音频流播放场景的需求是播放 WAV/MP3 文件的同时波形图要跟着走。如果只是打开一个独立的文件解析波形也可以但那不是实时的。这里我采用的是ISampleProvider 管道拦截的方案NAudio 播放组件在最终把数据交给声卡之前会调用一个我们自定义的 provider 的 Read 方法。这个方法收到的 buffer 就是从文件解码出来的最终采样数据我们在返回给声卡前先截一份副本给波形绘制模块。public class WaveformSampleProvider : ISampleProvider { private readonly ISampleProvider sourceProvider; public event Actionfloat[], int SamplesReady; public WaveFormat WaveFormat sourceProvider.WaveFormat; public WaveformSampleProvider(ISampleProvider source) { sourceProvider source; } public int Read(float[] buffer, int offset, int count) { int sampleCount sourceProvider.Read(buffer, offset, count); // 把本次要送往声卡的数据复制一份给外部模块 float[] data new float[sampleCount]; Array.Copy(buffer, offset, data, 0, sampleCount); SamplesReady?.Invoke(data, sampleCount); return sampleCount; } }使用时把 AudioFileReader 包进这个类再交给 WaveOutEventvar reader new AudioFileReader(test.wav); var waveformProvider new WaveformSampleProvider(reader); var waveOut new WaveOutEvent(); waveOut.Init(waveformProvider); waveOut.Play();AudioFileReader 是 NAudio 里的全能读取器能处理 WAV、MP3、AAC 等多种编码这样播放带波形的特性就支持了几乎所有常见音频格式。这个方法有一个优点值得强调它拿到的数据就是最终送到声卡的 PCM 数据即使后面有音量控制、淡入淡出等处理波形和实际听感仍然一致。这也呼应了项目标题里强调的从音频流数据获取——因为从设备监听得到的往往滞后或带噪声而这条链路是零延迟且无损的。4.2 播放时的文件与流管理用 AudioFileReader 播放要注意及时释放非托管资源。播放完或用户点击停止时务必调用 waveOut.Stop()、waveOut.Dispose()、reader.Dispose()否则声卡资源不释放下次播放可能报设备被占用。我实际使用中还发现如果采用直接读取文件的路线要在播放前先把 WaveOutEvent 的 DesiredLatency 设置成 300ms 上下太小容易出现播放咔哒声太大则声音迟钝。提示WaveOutEvent 的 DeviceNumber 留 -1 表示使用系统默认输出设备如果你的程序要支持选择扬声器和蓝牙耳机可以通过 WaveOutEvent.DeviceCount 枚举设备。5. 波形绘制算法的工程细节5.1 块式峰值检测不用画每个采样点如果每次拿到 44100Hz 的原始采样数据并全部画到控件上算下来每秒要画几万个点UI 线程根本扛不住。我的做法是把数据分成若干块每块只取最大绝对峰值然后只把这些峰值点画出来。这个思路可以和音量的柱状图类比——每个块相当于一个时间段峰值是这段时间的显著特征。画完整波形需要的点数取决于控件宽度比如宽度 800px那就把数据分成 800 段取峰值每个像素一列。private float[] ComputePeakEnvelope(float[] samples, int targetWidth) { if (samples.Length 0) return new float[targetWidth]; int blockSize samples.Length / targetWidth; if (blockSize 1) blockSize 1; float[] peaks new float[targetWidth]; for (int i 0; i targetWidth; i) { float maxPeak 0f; int start i * blockSize; int end Math.Min(start blockSize, samples.Length); for (int j start; j end; j) { float abs Math.Abs(samples[j]); if (abs maxPeak) maxPeak abs; } peaks[i] maxPeak; } return peaks; }如果你只需要一条简洁的轮廓线直接用上面这个数组即可。如果要像音频编辑器那样画实心波形上下对称的填充效果通常把每个块的负峰值和正峰值分别记录下来画两条对称线。5.2 双缓冲绘制与位图预渲染WinForms 里画波形最简单的方案是在 PictureBox 的 Paint 事件中直接画线但这样每帧都要清空重画闪烁非常明显。必须开启双缓冲。两种方式任选其一在窗体构造函数设置DoubleBuffered true或对 PictureBox 设置SetStyle(ControlStyles.AllPaintingInWmPaint | ControlStyles.UserPaint | ControlStyles.OptimizedDoubleBuffer, true)。更稳妥的做法把波形画到一张 Bitmap 上然后用 Graphics.DrawImage 一次性贴到控件上这和双缓冲效果类似但控制更灵活。我最常用的是方案二因为还能顺便保存截图也不需要担心其他控件抢焦点时把 Paint 弄乱。核心绘制代码如下private void RenderWaveform(float[] peaks) { using (Bitmap bmp new Bitmap(pictureBoxWave.Width, pictureBoxWave.Height)) { using (Graphics g Graphics.FromImage(bmp)) { g.Clear(Color.White); int midY pictureBoxWave.Height / 2; // 画中线 using (Pen penLine new Pen(Color.LightGray, 1f)) { g.DrawLine(penLine, 0, midY, pictureBoxWave.Width, midY); } using (Pen penWave new Pen(Color.DodgerBlue, 1f)) { int step pictureBoxWave.Width / peaks.Length; if (step 1) step 1; for (int i 0; i peaks.Length; i) { int yTop midY - (int)(peaks[i] * (pictureBoxWave.Height / 2f - 5f)); int yBottom midY (int)(peaks[i] * (pictureBoxWave.Height / 2f - 5f)); g.DrawLine(penWave, i * step, yTop, i * step, yBottom); } } } // 以位图形式更新 PictureBox pictureBoxWave.Image?.Dispose(); pictureBoxWave.Image (Bitmap)bmp.Clone(); } }图形逻辑的核心在于把peaks[i]0~1 的归一化浮点映射到控件纵向的像素坐标。注意两侧留 5 像素左右的边距避免波形接触控件上下边缘显得很难看。5.3 多久刷新一次波形才能保证流畅又不耗电很多人都默认刷新越快越好这其实是个误区。波形图不同于视频它没有必须达到多少帧的硬性要求视觉上只要波形在移动、能反映声音节奏变化就够了。我实测下来的经验刷新间隔主观感受CPU 占用30ms非常流畅但 UI 闪烁偏高50ms流畅无明显延迟适中100ms流畅能接受低200ms能看出停顿不太跟手极低这在录音场景中比较推荐 50~100ms。如果你做的是音乐可视化比如那种跟随节奏跳动的炫酷波形可以缩到 30ms如果是录音质检这种纯功能型工具100ms 完全够用还能减少刷新带来的性能消耗。另外有一个重要的细节在 Timer 里画图时不要重建 Pen、Bitmap 这种对象能缓存的对象在构造函数里初始化只在 Dispose 时销毁。反复创建 GDI 对象容易导致句柄泄漏长时间运行系统会越来越卡最后直接抛 OutOfMemoryException其实是 GDI 句柄耗尽。6. 常见问题与排查技巧实录6.1 录制时波形不更新但文件却是正常的症状文件里录的有声音波形图却像一条直线。这个 90% 的情况是跨线程访问问题。DataAvailable 在后台线程触发里面把采样数据塞入队列但 Timer 的 Tick 事件没去消费队列或者消费的是另一个空队列。排查方法在 OnDataAvailable 里加一个断点或者 Console.WriteLine先确认这个回调到底有没有触发。如果触发频繁但界面不动那肯定是 UI 线程和录音线程的数据没有接上。用 ConcurrentQueue 或加锁的 Queue 就能解决。6.2 播放时出现设备正在使用异常原因和排查思路通常集中在资源释放不彻底上。我调试时发现如果上一次播放的 WaveOutEvent 没有 Dispose下一次初始化就会爆这个错。后来我专门写了一个 StopAndDispose 方法统一处理private void SafeStopPlayback() { if (waveOut null) return; waveOut.Stop(); waveOut.Dispose(); waveOut null; reader?.Dispose(); reader null; }在每次播放前调用一遍 SafeStopPlayback()再重新创建对象就不会有问题了。6.3 波形看起来上下不对称这个通常是显示算法的问题不是音频本身的问题。因为 16bit PCM 是带符号的0 值居中负半周和正半周理论上应该对称。如果画实心波形时用的峰值是绝对最大值那必然会出现上下不对称——因为一个块里可能正半周的峰是 0.8负半周的峰是 0.6你取绝对值最大值后画成对称图形就失真了。解决办法是分别记录正负峰值// 正峰值记录最大值负峰值记录最小值 if (samples[j] posPeak) posPeak samples[j]; if (samples[j] negPeak) negPeak samples[j];然后画两条线一条从 negPeak 到 posPeak像示波器那种显示方式。6.4 内存占用不断增长长时间录音时如果内存一直涨需要检查这几个地方采样数据队列是否设置了上限。录音一两个小时不停机如果你的队列不限制长度迟早内存爆炸。我的做法是超过 N 个块就丢弃最旧的只保留最近 1 秒的数据用于绘制。WaveFileWriter 是否每写一段就刷新一次。如果写盘太频繁反而拖慢性能一般每秒钟 DataAvailable 触发 20 次每次都 flush 到磁盘没必要。NAudio 默认 Stream 有内部缓冲写完文件后 Dispose 时才会完整写头。Bitmap 是否没释放。每次 DrawImage 前先 Dispose 旧图不然 PictureBox.Image 换图时旧图成了无根对象GC 虽然会回收但 GDI 资源不会立刻释放。7. 总结我的实际体会这个项目做下来最大的收获在于理解了从音频流数据获取波形这句话的价值。数据显示和音频处理最怕的就是各走各的路即使你用绝对精确的时钟设备端采集和文件写入天然有微小偏差把这个偏差处理好是一件非常麻烦的事。而 NAudio 提供的事件和数据管道让波形模块能无缝地接入主链路这不仅简化了代码也让整个系统更健壮。做这类功能有一点一定要记住音频流的是一条单向管道可视化只是旁路监听。决定录出来音质好不好的永远是采集链路本身波形显示别去给主链路添乱。如果你正打算做录音可视化不妨先跑通音频的录放功能再逐步接入波形绘制每加一层就验证一次这样出问题时你永远不会手忙脚乱。如果想在这个项目上继续扩展可以考虑把波形图改成声谱图用 FFT 计算频率分布或者加上音量条和分贝显示器数据源头完全不用动。祝大家画波愉快。本文还有配套的精品资源点击获取