简介面向WPF初、中级开发者的录音与音频播放实战资源基于.NET Framework 4.5与Visual Studio 2017集中解决WPF应用中音频采集、播放控制、UI联动和本地音频信息读取等常见需求适用于聊天软件、教育工具等场景。压缩包共175个文件包含45个C#源码、13个DLL动态库、9个BAML界面编译文件、5个WAV测试音频以及xaml、config、exe等类型整体约3.18MB目前已有926人学习下载。资源内容围绕NAudio库与MediaPlayer类展开既演示了通过WasapiLoopbackCapture捕获声卡数据并写入文件的完整录音流程也给出了音频文件加载、播放、暂停、继续、停止及资源释放的调用示例。同时结合WPF按钮事件绑定说明如何触发录音与播放并利用AudioFileReader获取音频时长等元信息按需查阅这些代码与配套工程文件可少走弯路快速搭建具备基础音频处理能力的WPF应用。1. wpf 录音和播放音频先解决“采集端和播放端各管一段”的问题wpf 录音和播放音频最容易被导航带偏的地方是把“录音”和“播放”当成同一个问题去查资料。SoundPlayer 点几下就能播 WAV但录音涉及设备句柄、缓冲区、线程回调和文件头写入两件事放在同一个窗口时方案往往一拍脑袋就定了。我建议动手前先想清楚三件事录多长时间、存成什么格式、播放是否需要音浪反馈。这三个答案直接决定你是用 NAudio 包办采集与播放还是 SoundPlayer、MediaPlayer 各管一段。这篇按采集、播放、UI 集成、排错、验证的顺序展开适合正在 WPF 里做语音备忘录、通话质检或本地音频采集的 .NET 开发者。2. 录音链路为什么绕不开 NAudio从设备枚举到 WAV 落盘的完整代码2.1 WPF 没有“开箱即用”的录音 API选型其实只有三条路WPF 本身没有暴露麦克风采集接口。常见选择有三条路一是用 NAudio 这类托管封装库底层映射到 Windows 的 waveIn / WASAPI二是通过 WinRT 的 MediaCapture但这套 API 主要面向 UWP / .NET MAUI 场景传统 WPF 桌面项目里要处理权限模型和异步生命周期的成本很高三是自己 P/Invoke waveInXxx 系列函数完整走一遍设备句柄、缓冲区队列和回调工作量约等于重造半个 NAudio。我一般直接选 NAudio。理由不是它的 API 最简单而是它的 WaveInEvent 把设备枚举、缓冲区管理和回调线程都整理好了出错时你能把精力放在“音频数据怎么处理”上而不是“Windows 底层为什么又给我一个空指针”。如果你评估过 .NET MAUI会发现那边的录音方案基本走 MediaCapture代码和 NAudio 不通用所以别抱着“跨平台”的心态在 WPF 里选型先把当前项目的桌面场景做扎实。2.2 最小可用录音机枚举设备、打开流、把数据写进 WAV先从枚举设备开始。多麦克风环境里DeviceNumber 写死 0 经常会录到立体声混音甚至空设备所以第一步是把设备列表打出来确认下标。for (int i 0; i WaveInEvent.DeviceCount; i) { var caps WaveInEvent.GetCapabilities(i); Console.WriteLine(${i}: {caps.ProductName}); }这段代码返回的是当前 Windows 已识别的录音设备ProductName 通常是“Microphone Array”“Realtek High Definition Audio”之类。拿到下标后把它作为 DeviceNumber 传给录音器不要用控件的默认 0。设备插拔后下标可能变化所以正式项目里最好在启动时扫描一次并存起来。接下来是最小录音实现。重点是把 WaveInEvent 的生命周期挂到类字段上而不是放进一个局部方法里。// 录音核心WaveInEvent 负责采集WaveFileWriter 负责把 PCM 写进 WAV private WaveInEvent _waveIn; private WaveFileWriter _writer; private string _savePath; void StartRecording(string filePath) { _savePath filePath; _waveIn new WaveInEvent { DeviceNumber 0, // 用刚才枚举出来的下标 BufferMilliseconds 50, // 每 50ms 回调一次越小越跟手越小越容易丢 WaveFormat new WaveFormat(44100, 16, 1) // CD 音质采样率16bit单声道 }; _waveIn.DataAvailable OnDataAvailable; _waveIn.RecordingStopped OnRecordingStopped; _writer new WaveFileWriter(filePath, _waveIn.WaveFormat); _waveIn.StartRecording(); } private void OnDataAvailable(object sender, WaveInEventArgs e) { // e.Buffer 是字节数组e.BytesRecorded 是本次实际收到的字节数 _writer?.Write(e.Buffer, 0, e.BytesRecorded); } private void OnRecordingStopped(object sender, StoppedEventArgs e) { _writer?.Dispose(); _writer null; _waveIn?.Dispose(); _waveIn null; } void StopRecording() { _waveIn?.StopRecording(); }这段代码逻辑很简单但值得拆开说明。WaveInEvent 每间隔 BufferMilliseconds 产生一次 DataAvailable这里的 Buffer 不是“一块固定 2048 字节”的包而是每次采集到的 PCM 字节直接交给 WaveFileWriter 写入即可。采样率决定了数据回调的节奏44100Hz、16bit、单声道时每秒大约 88200 字节那么 50ms 就是约 4410 字节。关于采样率的选择语音备注用 44100 或 48000 都行但注意要和后续播放设备、转写服务的要求对齐。如果只是普通对话记录22050Hz 也能听清文件体积直接减半。录音格式如果要降噪处理后期一般再统一转不建议在采集端就牺牲太多信息量。2.3 停止录音与释放设备顺序写反就是设备占用WaveInEvent 的 StopRecording 不是立即停止它只是发一个停止请求随后在后台线程触发 RecordingStopped 事件事件触发时缓冲区里的最后一段数据可能还没写入文件。所以停止流程要做成异步的StopRecording 之后不要立刻把 _writer 置空而是在 OnRecordingStopped 里统一收尾。常见错误是在 StopRecording 方法里直接写 _writer.Dispose()结果 WAV 文件头长度字段没回写播放器能打开文件但进度条不走或者时长读出 0。WaveFileWriter 在 Dispose 时会回写 RIFF 头必须等所有 DataAvailable 都结束后再释放。我的习惯是保持上面代码的结构Stop 只负责请求停止Dispose 统一在 RecordingStopped 里处理。另外注意StopRecording 后到 RecordingStopped 触发之间DataAvailable 可能还会来一两次。这时 _waveIn 已经不再采集但事件队列里还残留数据所以写入前要判空。如果你在 Stop 之后立刻尝试修改 UI 上的状态也会因为事件还在后台线程而出现意外。提示WaveInEvent.Repeated 参数通常不用改。它是兼容老式 waveIn 驱动的外部循环标志桌面环境下默认 false 就是对的。别看到文档里出现“repeated”就去调调错会导致录音数据重复写入。3. 播放音频的三种姿势SoundPlayer、MediaPlayer、NAudio 怎么选3.1 SoundPlayer零依赖但只认 WAV适合提示音System.Media.SoundPlayer 是 WPF 里最轻量的播放方案不需要引入任何 NuGet 包只支持 WAV 格式。它的定位是操作提示音、消息提醒这一类短音频而不是长录音回放。using System.Media; var player new SoundPlayer(notice.wav); player.Load(); // 同步加载文件大时会卡 UI player.Play(); // 异步播放不阻塞界面线程 // player.PlaySync(); // 阻塞到播完适合做“确认音” // player.PlayLooping(); // 循环播放慎用容易忘记 stop这段代码里 Load 和 Play 的区别要讲清Load 是同步加载会把整个 WAV 读入内存Play 启动后台播放立即返回。如果拿 SoundPlayer 去播一段几分钟的录音内存占用和加载卡顿都受不了。还要注意它没有内置音量控制接口想调音量只能操作系统混音器这对一个演示项目来说很不友好。所以我的边界判断是文件小于 1MB纯提示音选 SoundPlayer其余情况换方案。3.2 MediaPlayer让系统解码 MP3/AAC别自己碰压缩格式WPF 自带的 System.Windows.Media.MediaPlayer 是另一个“零额外依赖”方案它底层走 Windows Media Foundation可以解码 MP3、AAC、WMA 等压缩格式不用自己处理压缩音频解码。播放前直接 Open 一个 Uri比 SoundPlayer 能力范围宽很多。var media new System.Windows.Media.MediaPlayer(); media.Open(new Uri(D:\audio\sample.mp3, UriKind.Absolute)); media.Volume 0.8; // 0 到 1直接可调 media.MediaEnded (s, e) media.Close(); media.Play();MediaPlayer 的 Open 是异步准备调用后不能立刻 Play要先等 MediaOpened 或者直接让状态机自动进入 Buffering。它还有个特点Play 之后声音从系统默认输出设备走和 WPF 窗口本身无关。你没法拿到每一帧的音频数据去做音浪显示也没有逐帧 seek 回读的能力这些限制决定了它适合“把一条录音放给用户听”不适合做音频分析或播放进度裁剪。3.3 NAudio 播放当你要控制进度、音量和数据用它就对了录音已经引用了 NAudio播放端如果也用它整个项目只需要维护一套音频抽象。NAudio 的播放思路是把音频文件解码成 PCM然后送给 WaveOutEvent 这个输出设备。using NAudio.Wave; var reader new AudioFileReader(D:\audio\sample.mp3); var output new WaveOutEvent { DesiredLatency 200, // 输出缓冲 200ms音画同步要求高时调小 NumberOfBuffers 3 // 缓冲块数太小容易破音 }; output.Init(reader); output.Play(); // 停止和释放时顺序不能反 output.Stop(); output.Dispose(); reader.Dispose();这里 AudioFileReader 会自动识别文件类型并解码成 PCMWaveOutEvent 则负责把 PCM 送到声卡。注意 Init 之后不要立刻 Dispose reader播放引擎还在异步读取它的数据。DesiredLatency 是输出延迟指标设 50ms 能大幅降低“按键后出声”的延迟但系统负载高时更容易出现爆音设 200ms 更稳妥。做语音对讲类的项目我会从 100ms 开始试做提示音则无所谓。三种方案的取舍我用一张表记录在项目文档里方案支持格式延迟控制数据可读性适合场景SoundPlayer仅 WAV基本不可控无短提示音、零依赖MediaPlayerMP3/AAC/WMA 等系统级无录音回放、背景音乐NAudio视 Reader 而定基本全覆盖可调缓冲可逐帧处理需要音浪、进度分析、低延迟如果只是做录音回放MediaPlayer 足够但你已经为录音引入了 NAudio播放端再用它至少省掉“两种播放状态各自维护”的心智负担。我个人的分工是系统提示音走 SoundPlayer录音回放走 MediaPlayer需要实时音浪或裁剪的音频走 NAudio。4. 把录音塞进 WPF UI时长显示、音浪与 MVVM 的正确姿势4.1 DataAvailable 跑在后台线程更新界面必须过 DispatcherWaveInEvent 的 DataAvailable 事件是在后台线程触发的这一点新手翻车率极高。直接在事件里写 _textBlock.Text ...看起来偶尔能跑但一旦数据量大、界面刷新频繁就会随机抛“调用线程无法访问此对象”。private void OnDataAvailable(object sender, WaveInEventArgs e) { // DataAvailable 在后台线程触发不能直接碰控件 float rms ComputeRms(e.Buffer, e.BytesRecorded); Application.Current.Dispatcher.BeginInvoke(new Action(() { _volumeBar.Value rms * 100; })); }这段代码把音频分析放在后台线程只把“结果值”通过 Dispatcher 回 UI 线程。注意 BeginInvoke 是异步投递高频调用时 UI 队列里会积累大量委托导致界面卡顿。我在实际项目里会加一个节流记录上一次刷新的时间如果距上次超过 50ms 才再次投递。音浪条的刷新率 20 次/秒人眼已经觉得很流畅没必要跟着每次采集回调走。如果你的项目用 MVVM我建议把 AudioRecorder 封装成一个服务暴露 SampleLevel 和 StateChanged 事件ViewModel 订阅后转换成普通属性。不要在事件里直接拿 View 的引用否则后续换界面样式时音频逻辑会和控件绑死。4.2 时长显示别靠“数缓冲块”用 DispatcherTimer 对齐录音状态很多初学者用统计 DataAvailable 次数来估算录音时长这是踩坑起点。DataAvailable 的触发频率受 BufferMilliseconds 影响还受系统调度波动累计次数乘上 50ms 得到的时长经常比真实时间慢或快。正确做法是单独用 Stopwatch 计时再配合 DispatcherTimer 刷新文本。private Stopwatch _stopwatch; private DispatcherTimer _timer; void StartTimer() { _stopwatch Stopwatch.StartNew(); _timer new DispatcherTimer(DispatcherPriority.Render) { Interval TimeSpan.FromMilliseconds(200) }; _timer.Tick (s, e) { if (_recording) { _txtDuration.Text _stopwatch.Elapsed.ToString(hh\:mm\:ss); } }; _timer.Start(); }DispatcherTimer 虽然跑在 UI 线程但它的 Tick 不会在文本框频繁重绘时产生剧烈竞争因为 200ms 刷新一次足够满足显示需求。重点是把 _recording 这个标志位放在哪里在录音服务里要有一个 IsRecording 属性UI 的 Tick 里判断它而不是用“Timer 是否启动”来推断录音状态否则 Stop 之后还有最后一次 Tick 会把多余时间显示出来。4.3 录音对象该放哪字段、单例还是 ViewModel录音对象不能放在函数局部变量里这是所有问题的根源。WaveInEvent 是托管对象局部函数执行完毕、没有引用后GC 随时可能回收它表现就是“录 3 秒后静音”或“完全没有回调”。我的方案是把录音器提升到窗体类字段或者封装成单例服务。前者适合单窗口工具后者适合跨页面共享采集能力的项目。如果做 MVVM录音服务最好实现 IDisposable 并注册到容器里。但 AttentionWPF 的 Window 关闭不保证立即 Dispose要在 Closing 事件里主动调用。否则会出现“程序关了麦克风灯还亮着”的诡异现象。这个问题的排查成本不低一开始就按生命周期管理来做能省很多事。界面库对录音没有帮助。HandyControl、MaterialDesign 这类 UI 库能给你漂亮的按钮和进度条但音频设备采集仍然要自己接别指望靠控件库省掉音频层的代码。5. 录音和播放的常见问题排查5 个高频坑与修复顺序5.1 录出来是 0 字节或文件头损坏现象录音结束后文件存在但打开时长是 0甚至播放器直接报文件损坏。 原因WaveFileWriter 还没写完 RIFF 头就被中途释放或者在 DataAvailable 还在写入时就把 _writer 置空并关闭了。WaveFileWriter 的头部长度字段是在 Dispose 时统一回写的提前关闭等于写了一个“永远不知道长度”的残缺文件。 解决把 writer.Dispose() 统一放在 RecordingStopped 事件里执行不要在 Stop 按钮的点击方法里急着释放。StopRecording 只调用 Stop收尾全部交给事件。5.2 录音只有前几秒后面全是静音现象前 3 秒有声音后面波形平直停止时还能正常生成文件。 原因录音对象被 GC 回收。这是最隐蔽的一类问题因为界面线程没有崩溃设备可能彻底关闭或被系统静默挂起。 解决把 WaveInEvent 实例挂在类字段或服务容器里保证整个录音期间都存在强引用。排查时可以临时在 DataAvailable 里写一个日志看回调是否在某条时间点后突然消失。5.3 二次录音报“设备被占用”现象第一次录完一切正常第二次点击录音瞬间抛异常或者没有任何回调。 原因第一次停止后没有 Dispose设备句柄还占着。WaveInEvent.StopRecording() 只停止采集不释放设备。Windows 对独占采集设备的占用很敏感不释放的下场就是其他进程也没法用。 解决在 RecordingStopped 里执行 _waveIn?.Dispose() 并把引用置空。再录之前重新 new WaveInEvent不要反复 stop / start 同一个实例。5.4 播放时爆音、卡顿尤其是边录边放现象用 NAudio 播放录音时出现周期性“咔哒”声或者播放进度忽快忽慢。 原因WaveOutEvent 的 DesiredLatency 设置过小系统在 CPU 繁忙时没有及时填满输出缓冲导致声卡缓冲下溢。录音和播放同时进行时磁盘写入和采集回调会抢资源问题更容易爆发。 解决把 DesiredLatency 调回 200msNumberOfBuffers 给 3 或 4。同时确认录音采样率和播放端一致48kHz 素材用 44.1kHz 设备播放不仅变调还叠加爆音。5.5 录到的声音里混进了电脑播放的声音现象戴着耳机说话录音里却包含系统提示音或室友正在播放的视频声音。原因音频设备选了“立体声混音”或“Wave Out Mix”这类设备走的是声卡内部回环专门采集扬声器输出。笔记本电脑尤其容易默认指向混音设备。 解决回到 2.2 小节的设备枚举代码把列表打出来确认选中的是“Microphone Array”“External Mic”这类输入设备而不是带“Mix”“Loopback”“Stereo Mix”字样的项。部分设备驱动会把混音设备放在列表最前面肉眼确认比盲选靠谱。6. 验证与进阶用回放、静音检测和波形盯住采集链路6.1 用回放比对法验证“录进去的内容和听感一致”录音完成后立刻用 MediaPlayer 做一次回放人工确认高频噪声、音量起伏是否符合预期。这一步能快速暴露采样率错配、声道反转这类自动测试发现不了的问题。比对时注意用耳机不要用外放否则麦克风会把回放声音再录回去形成二次混合你会误判成回声问题。我还会额外做一个回环测试把播放设备和录音设备的采样率都固定成 44100Hz录一段 1kHz 正弦波再播放出来听音调是否准确。如果播放比原来低说明录音链路的采样率被悄悄换了多半是某个设备驱动强制用了 48kHz。6.2 用 RMS 判断“录了但全是静音”的伪成功文件能生成、时长也对但内容全是静音是另一个高频假象。手动听一个 10 分钟文件代价太大我会直接在 DataAvailable 里算 RMS再决定要不要在录音结束后提示用户。// 计算 16bit 单声道 PCM 的 RMS 电平返回 0 到 1 float ComputeRms(byte[] buffer, int bytesRecorded) { int sampleCount bytesRecorded / 2; double sum 0; for (int i 0; i bytesRecorded; i 2) { short sample BitConverter.ToInt16(buffer, i); sum sample * (double)sample; } double rms Math.Sqrt(sum / sampleCount); return (float)(rms / short.MaxValue); }这段代码每 16bit 取一个样本累加平方后开根号再归一化。RMS 低于 0.01 基本就是静音0.1 到 0.3 属于正常说话音量。如果单句 RMS 长期低于阈值说明麦克风增益不足或设备选错。把 ComputeRms 和音浪条串联录完还能顺手生成一张音量统计判断整段录音是否存在大量低电平区域。6.3 下一步玩法把 WAV 直接喂给本地转写服务录音文件已经是标准 WAV后续可以交给本地部署的语音转写服务做会议纪要或通过离线 ASR 转成文字后做全文检索。这一步不需要动录音代码只要保证采集格式和转写服务要求的采样率一致通常设置成 16000Hz 或 44100Hz 单声道。我现在的习惯是接到 WPF 音频需求先问三件事录多久、存成什么格式、播放要不要跟手然后再写第一行代码。音频链路不复杂但线程模型和资源释放的坑很密集先定好生命周期能省掉你后面一整天的排查时间。希望帮到你。本文还有配套的精品资源点击获取