1. 为什么要在Unity里搞离线语音合成如果你正在开发一款需要语音交互的Unity应用比如游戏里的NPC对话、教育软件里的语音讲解或者任何需要即时语音反馈的交互式应用那你肯定遇到过一个问题延迟。传统的云端TTS文本转语音服务虽然音质不错但一来需要网络二来有网络延迟用户说完话或者触发事件后总要等那么零点几秒甚至一两秒才能听到声音体验一下子就割裂了。我当初做项目时就深受其害。一个需要实时对话的虚拟角色每次等云端返回音频用户都以为卡住了。后来我发现了sherpa-onnx这个宝藏。它是一个完全离线的、跨平台的语音AI工具包核心是把训练好的语音模型比如VITS转换成ONNX格式然后用ONNX Runtime来推理。这意味着你可以在Unity里不依赖网络直接调用本地模型生成语音延迟可以压到很低。更重要的是sherpa-onnx支持流式合成。这不是简单的“生成完整音频再播放”而是像流水线一样模型生成一点音频数据Unity这边就立刻播放一点。理想情况下用户几乎感觉不到延迟语音是“流”出来的体验非常丝滑。这对于需要即时反馈的VR/AR应用、实时对话机器人、或者任何对响应速度有要求的场景简直是刚需。所以这篇文章就是把我踩过的坑、试出来的最佳实践特别是如何实现低延迟的流式语音合成以及怎么解决过程中遇到的奇葩问题比如音频采样率不对、奇怪的尾音都分享给你。咱们不搞复杂的理论直接上手让你能在自己的Unity项目里快速用起来。2. 前期准备模型、库与环境搭建万事开头难但把环境搭好就成功了一半。这里我带你一步步来避开我当初遇到的坑。2.1 获取sherpa-onnx的Unity库文件sherpa-onnx官方并没有直接提供一个开箱即用的Unity Package。我们需要从它的C# API入手。最直接的方法是去GitHub仓库k2-fsa/sherpa-onnx的Release页面或者从它的C#示例项目中找到编译好的动态链接库DLL。不过已经有热心的开发者把这块工作做了并开源了项目就是原始文章里提到的usherpa-onnx-tts。我强烈建议你直接克隆或下载这个项目作为起点它能帮你省去很多编译和配置的麻烦。# 你可以通过Git克隆这个仓库 git clone https://gitee.com/awnuxcvbn/usherpa-onnx-tts.git这个仓库里已经包含了适配Unity的SherpaOnnx.dll、onnxruntime.dll等必要的本地库文件通常放在Plugins文件夹下。针对不同平台Windows、Android、iOS你需要准备对应的库文件。对于Windows编辑器下开发主要关注x86_64的DLL就行。2.2 下载并配置语音合成模型sherpa-onnx支持多种TTS模型比如VITS、Piper等。原始文章作者测试了vits-zh-aishell3这是一个中文女声模型。根据我的经验后来更新的几个模型音质更好比如vits-zh-hf-theresa、vits-zh-hf-eula等你可以根据喜好选择。模型可以从官方页面下载https://k2-fsa.github.io/sherpa/onnx/tts/pretrained_models/index.html。下载后你会得到一个包含多个文件的模型包通常有*.onnx 核心的模型文件。tokens.txt 音素或字符的词表文件。lexicon.txt 词典文件某些模型需要。*.fst 文本正则化规则文件用于处理数字、日期等。关键一步在Unity项目中你需要将这些模型文件放到StreamingAssets文件夹下。这是因为Application.streamingAssetsPath在Unity中是一个可靠的、跨平台的只读路径特别适合存放这种不需要动态修改的资源。在你的项目Assets目录下创建StreamingAssets文件夹然后把模型解压后的整个文件夹例如vits-zh-aishell3放进去。你的目录结构应该看起来像这样你的Unity项目/ ├── Assets/ │ ├── StreamingAssets/ │ │ └── vits-zh-aishell3/ │ │ ├── vits-aishell3.onnx │ │ ├── tokens.txt │ │ ├── lexicon.txt │ │ └── rule.fst (或 phone.fst, date.fst, number.fst) │ ├── Plugins/ │ │ ├── x86_64/ │ │ │ ├── SherpaOnnx.dll │ │ │ └── onnxruntime.dll │ │ └── (其他平台库文件) │ └── Scripts/ │ └── TTS.cs (我们即将编写的脚本)2.3 在Unity中配置API兼容性由于sherpa-onnx的C# API可能会用到一些较新的.NET API你需要确保Unity的脚本运行时版本支持。打开Player Settings菜单栏Edit - Project Settings - Player在Other Settings区域将Api Compatibility Level设置为.NET Framework而不是.NET Standard 2.0或.NET Standard 2.1。.NET Framework的兼容性最好能避免很多奇怪的DLL加载错误。另外在Configuration下将Scripting Backend设置为Mono。虽然IL2CPP性能更好但在开发调试阶段Mono对原生插件DLL的支持更直接问题更少。等项目稳定后可以再尝试切换到IL2CPP并打包测试。3. 从基础到流式两种集成方式详解有了环境和模型我们就可以开始写代码了。我会从最基础的“生成完整音频文件”开始再升级到“实时流式播放”这样你能更清楚其中的演进和优化点。3.1 基础集成生成WAV文件再播放这是最直观的方式也是官方示例的常见做法。思路很简单给定一段文本调用sherpa-onnx生成完整的音频数据保存为WAV文件然后用Unity的AudioSource加载并播放。using UnityEngine; using System.IO; using SherpaOnnx; // 引入sherpa-onnx的C#命名空间 using System.Runtime.InteropServices; public class BasicTTS : MonoBehaviour { public string modelName vits-zh-aishell3; public string textToSpeak 这是一个语音合成测试; public int speakerId 99; // 某些VITS模型支持多说话人通过ID选择 void Start() { // 1. 构建模型文件的完整路径 string streamingAssetsPath Application.streamingAssetsPath; string modelPath Path.Combine(streamingAssetsPath, modelName, vits-aishell3.onnx); string tokensPath Path.Combine(streamingAssetsPath, modelName, tokens.txt); string lexiconPath Path.Combine(streamingAssetsPath, modelName, lexicon.txt); // 2. 配置TTS引擎 var config new OfflineTtsConfig(); config.Model.Vits.Model modelPath; config.Model.Vits.Lexicon lexiconPath; config.Model.Vits.Tokens tokensPath; config.Model.Vits.NoiseScale 0.667f; // 控制合成语音的随机性/自然度 config.Model.Vits.NoiseScaleW 0.8f; // 控制音素时长的随机性 config.Model.Vits.LengthScale 1.0f; // 语速1变慢1变快 config.Model.NumThreads 1; // 使用的CPU线程数根据设备调整 config.Model.Debug 0; // 关闭调试信息 config.Model.Provider cpu; // 使用CPU推理如果想用GPU可设为 cuda (需要对应库支持) // 3. 规则文件处理数字、日期等文本正则化 string ruleFstPath Path.Combine(streamingAssetsPath, modelName); config.RuleFsts string.Join(,, Path.Combine(ruleFstPath, phone.fst), Path.Combine(ruleFstPath, date.fst), Path.Combine(ruleFstPath, number.fst) ); config.MaxNumSentences 1; // 4. 创建TTS引擎并合成 using (var tts new OfflineTts(config)) { // 这里生成的是完整的音频对象 OfflineTtsGeneratedAudio audio tts.Generate(textToSpeak, speakerId: speakerId); // 5. 保存为WAV文件 string outputPath Path.Combine(Application.persistentDataPath, output.wav); bool success audio.SaveToWaveFile(outputPath); if (success) { Debug.Log($音频已保存至: {outputPath}); // 6. 在Unity中加载并播放这个WAV文件 StartCoroutine(LoadAndPlayAudio(outputPath)); } else { Debug.LogError(保存音频文件失败); } } } System.Collections.IEnumerator LoadAndPlayAudio(string filePath) { // 注意在Unity中直接加载本地文件需要使用 file:// 协议 string url file:// filePath; using (var www new UnityEngine.WWW(url)) { yield return www; AudioClip clip www.GetAudioClip(false, false, AudioType.WAV); AudioSource audioSource gameObject.AddComponentAudioSource(); audioSource.clip clip; audioSource.Play(); } } }这种方式的好处是简单、稳定适合对实时性要求不高的场景比如预生成游戏内的旁白。但缺点也很明显延迟高。你需要等待整个句子合成完毕、写入文件、再加载用户才能听到声音整个过程可能需要好几秒。3.2 进阶实现实时流式语音合成流式合成的核心思想是“边生成边播放”。sherpa-onnx的C# API提供了一个回调函数机制模型每生成一小段音频样本比如几百个采样点就会通过回调函数通知你。我们可以在回调函数里将这些样本数据立刻填充到Unity的AudioClip中并播放。这里有个关键点Unity的AudioClip需要预先知道音频的总长度和格式但流式合成开始时我们并不知道总长度。解决办法是使用一个“环形缓冲区”或者动态列表来接收数据并利用OnAudioFilterRead回调或动态创建AudioClip的方式来实时播放。下面是我优化后的一个流式TTS组件它可以直接挂载到GameObject上使用using UnityEngine; using System; using System.Collections.Generic; using System.IO; using SherpaOnnx; using System.Runtime.InteropServices; [RequireComponent(typeof(AudioSource))] public class StreamingTTS : MonoBehaviour { [Header(模型配置)] public string modelFolder vits-zh-aishell3; public int speakerId 99; [Header(音频设置)] public int sampleRate 22050; // 重要需要与模型输出采样率匹配 public int bufferSize 4096; // 音频缓冲区大小 private OfflineTts _ttsEngine; private AudioSource _audioSource; private Queuefloat _audioSampleQueue new Queuefloat(); private object _queueLock new object(); private bool _isPlaying false; private int _lastSamplePosition 0; void Start() { _audioSource GetComponentAudioSource(); InitializeTtsEngine(); } void InitializeTtsEngine() { try { string basePath Path.Combine(Application.streamingAssetsPath, modelFolder); var config new OfflineTtsConfig(); config.Model.Vits.Model Path.Combine(basePath, vits-aishell3.onnx); config.Model.Vits.Lexicon Path.Combine(basePath, lexicon.txt); config.Model.Vits.Tokens Path.Combine(basePath, tokens.txt); config.Model.Vits.NoiseScale 0.667f; config.Model.Vits.NoiseScaleW 0.8f; config.Model.Vits.LengthScale 1.0f; config.Model.NumThreads 2; // 可以适当增加线程数以加速推理 config.Model.Debug 0; config.Model.Provider cpu; // 设置规则文件 config.RuleFsts string.Join(,, Path.Combine(basePath, phone.fst), Path.Combine(basePath, date.fst), Path.Combine(basePath, number.fst) ); config.MaxNumSentences 1; _ttsEngine new OfflineTts(config); Debug.Log(TTS引擎初始化成功。); } catch (Exception e) { Debug.LogError($初始化TTS引擎失败: {e.Message}); } } // 公开方法开始流式合成并播放 public void Speak(string text) { if (_ttsEngine null) { Debug.LogWarning(TTS引擎未初始化); return; } // 停止当前播放并清空队列 StopSpeaking(); // 创建回调委托 OfflineTtsCallback callback new OfflineTtsCallback(OnAudioGenerated); // 在后台线程中开始生成避免阻塞主线程 System.Threading.ThreadPool.QueueUserWorkItem(_ { try { // 注意GenerateWithCallback 是同步调用会阻塞直到合成完毕 // 但它会通过回调函数多次返回音频数据片段 _ttsEngine.GenerateWithCallback(text, speed: 1.0f, sid: speakerId, callback: callback); Debug.Log(语音合成完成。); } catch (Exception e) { Debug.LogError($语音合成过程中出错: {e.Message}); } }); // 准备并开始播放即使还没有数据先播放静音 StartAudioPlayback(); } // 停止播放 public void StopSpeaking() { _isPlaying false; if (_audioSource.isPlaying) { _audioSource.Stop(); } lock (_queueLock) { _audioSampleQueue.Clear(); } _lastSamplePosition 0; } // 回调函数当模型生成了一部分音频数据时被调用 private void OnAudioGenerated(IntPtr samplesPtr, int numSamples) { // 将原生指针的数据复制到托管数组 float[] newSamples new float[numSamples]; Marshal.Copy(samplesPtr, newSamples, 0, numSamples); // 将新样本加入队列 lock (_queueLock) { foreach (var sample in newSamples) { _audioSampleQueue.Enqueue(sample); } } // 如果还没开始播放并且积累了一定数据就触发播放 if (!_isPlaying _audioSampleQueue.Count bufferSize / 2) { // 注意这个判断在主线程执行更安全可以通过标志位或事件通知主线程 } } private void StartAudioPlayback() { // 创建一个足够大的AudioClip来容纳流式数据这里先预设一个较大长度 // 实际播放中我们通过OnAudioFilterRead动态提供数据 AudioClip streamingClip AudioClip.Create(StreamingTTS, sampleRate * 10, 1, sampleRate, true, OnAudioRead); _audioSource.clip streamingClip; _audioSource.loop false; // 流式播放不循环 _audioSource.Play(); _isPlaying true; } // AudioClip的数据请求回调 private void OnAudioRead(float[] data) { lock (_queueLock) { int samplesNeeded data.Length; int samplesAvailable _audioSampleQueue.Count; if (samplesAvailable 0) { // 没有数据填充静音 for (int i 0; i data.Length; i) { data[i] 0; } // 如果长时间没数据可以停止播放 if (_isPlaying _lastSamplePosition sampleRate * 5) // 比如静音超过5秒 { MainThreadDispatcher.Enqueue(() { if (_audioSource.isPlaying) _audioSource.Stop(); _isPlaying false; }); } return; } // 有数据填充到data数组 int samplesToCopy Mathf.Min(samplesNeeded, samplesAvailable); for (int i 0; i samplesToCopy; i) { data[i] _audioSampleQueue.Dequeue(); } // 如果队列数据不够填满请求的数组剩余部分填0 for (int i samplesToCopy; i samplesNeeded; i) { data[i] 0; } _lastSamplePosition samplesToCopy; } } void OnDestroy() { if (_ttsEngine ! null) { _ttsEngine.Dispose(); } } } // 一个简单的工具类用于在主线程执行操作因为Unity API必须在主线程调用 public static class MainThreadDispatcher { private static readonly QueueAction _executionQueue new QueueAction(); public static void Enqueue(Action action) { lock (_executionQueue) { _executionQueue.Enqueue(action); } } // 需要在某个MonoBehaviour的Update中调用此方法 public static void ExecutePending() { lock (_executionQueue) { while (_executionQueue.Count 0) { _executionQueue.Dequeue()?.Invoke(); } } } }代码要点解析初始化在Start中初始化TTS引擎配置模型路径和参数。NumThreads可以适当调高如2或4以利用多核CPU加速合成但也要根据目标平台性能权衡。Speak方法这是触发合成的入口。它会在线程池中启动合成任务避免阻塞主线程。合成任务调用GenerateWithCallback并传入回调函数OnAudioGenerated。回调函数OnAudioGenerated这是流式的核心。模型每生成一段PCM样本float数组就会调用此函数。我们将数据存入一个线程安全的队列 (_audioSampleQueue)。音频播放OnAudioReadUnity的AudioClip在创建时如果标记为streamingtrue就会在需要数据时调用OnAudioRead回调。我们从这个队列中取出数据填充给Unity的音频系统。如果队列空了就填充静音0。主线程安全注意OnAudioGenerated是在合成线程中被调用的而修改Unity的AudioSource必须在主线程。我们通过一个简单的MainThreadDispatcher来派发任务。你需要在一个MonoBehaviour的Update中调用MainThreadDispatcher.ExecutePending()。实测下来使用这种流式方式从调用Speak到听到第一个声音延迟可以控制在1秒以内甚至更低这比生成完整文件再播放快了非常多。用户体验是“话音刚落语音即出”非常跟手。4. 实战中遇到的坑与优化方案理想很丰满现实很骨感。直接套用上面的代码你可能会遇到几个典型问题。下面就是我踩过的坑和解决办法。4.1 采样率问题为什么我的音频听起来像“快进”或“慢放”原始文章里作者就遇到了这个问题“不知为何生成的音频是8000HZ的……”。这会导致播放速度异常声音尖细或低沉。问题根源sherpa-onnx的VITS模型默认输出采样率可能是8000Hz或16000Hz但Unity中AudioClip的创建和AudioSource的播放默认期望的是常见的22050Hz或44100Hz。如果采样率不匹配播放时长就会错乱。解决方案你需要明确知道模型输出的采样率并在创建AudioClip时指定正确的采样率。查询模型输出采样率有些模型信息会在文档里写明。更直接的方法是在回调函数里打印出第一次接收到的数据长度和模型信息或者查阅sherpa-onnx的源码和Issue。对于vits-zh-aishell3我实测其输出采样率是22050Hz。而作者遇到的8000Hz可能是早期版本或特定配置下的输出。代码中明确指定在创建AudioClip时sampleRate参数必须与模型输出一致。// 在StartAudioPlayback方法中 int modelOutputSampleRate 22050; // 根据你的模型确定 AudioClip streamingClip AudioClip.Create(StreamingTTS, modelOutputSampleRate * 10, 1, modelOutputSampleRate, true, OnAudioRead);AudioSource设置确保场景中播放此AudioClip的AudioSource组件没有勾选bypass effects等可能影响采样率处理的选项。4.2 延迟优化如何让语音“秒出”虽然流式已经大幅降低了延迟但我们还想更快。目标是“首字延迟”尽可能短。预热模型在场景加载时或空闲期提前初始化TTS引擎 (new OfflineTts(config))。模型的第一次加载和初始化是最耗时的可能几百毫秒到几秒。提前做好这个工作等用户触发时直接调用GenerateWithCallback即可。调整模型参数NoiseScale和NoiseScaleW参数会影响生成速度和质量。适当降低这些值如从0.667/0.8降到0.3/0.5可能会轻微提升速度但可能会让语音听起来更机械。需要根据实际听感权衡。使用更小的模型sherpa-onnx提供了不同大小的VITS模型。例如vits-zh-aishell3是一个通用模型。你可以尝试寻找或转换更小、更快的模型虽然音质可能略有下降但对延迟敏感的应用来说是值得的。优化线程和缓冲区NumThreads设置在性能较强的设备上如PC可以设置为CPU核心数。在移动设备上建议设置为1或2避免线程切换开销。音频缓冲区bufferSize这个值越小延迟越低但可能增加CPU开销和音频卡顿的风险。我通常从1024或2048开始测试在目标设备上找到一个平衡点。在脚本中我设置了bufferSize 4096这是一个比较保守稳定的值。预加载常用短语如果你的应用有固定的、简短的语音反馈如“是”、“否”、“收到”可以在启动时预合成这些短语的音频并缓存起来使用时直接播放缓存实现零延迟。4.3 音质对比哪个模型更好听原始文章作者后来提到“测试了另外三个模型音质都高于vits-zh-aishell3 基本可用”。模型的选择对最终效果影响巨大。根据社区反馈和我自己的测试除了vits-zh-aishell3以下几个中文模型值得尝试模型名称特点推荐场景vits-zh-aishell3通用中文女声音质清晰稳定资源消耗中等。通用对话、旁白对稳定性要求高。vits-zh-hf-theresa音色更年轻、有活力情感表现力稍好。游戏角色、虚拟偶像需要更生动的语音。vits-zh-hf-eula音色偏成熟、稳重。新闻播报、知识讲解需要稳重感。vits-zh-hf-fanchen-C可能具有特定风格如可爱、温柔。特定角色配音需要风格化语音。vits-melo-tts-zh_en支持中英文混合。这是巨大优势应用中频繁出现中英文混读的场景。如何测试最好的方法就是下载不同的模型用同一段包含多种语气和数字的文本进行合成对比。注意替换代码中的modelFolder和对应的模型文件名如*.onnx文件名可能不同。4.4 平台兼容性编辑器正常打包后异常这是最让人头疼的问题之一。原始文章作者在2024年8月6日记录“从sherpa-onnx1.10.13 合成的语音会出现奇怪的尾音原因未知但仅出现在编辑器打包出的exe是正常的”。可能的原因和排查思路DLL依赖问题Unity编辑器通常是x86_64和打包后的独立应用也可能是x86_64可能加载了不同版本或不同路径的依赖DLL如onnxruntime.dll。确保Plugins文件夹下的库文件是针对目标平台正确编译的。有时候编辑器环境自带了一些运行时库而打包环境没有。模型文件路径在编辑器中Application.streamingAssetsPath指向Assets/StreamingAssets。打包后这个路径会变。我们的代码使用了Path.Combine(Application.streamingAssetsPath, modelFolder, ...)这本身是跨平台的正确写法。但请确保在打包时模型文件确实被包含在构建中StreamingAssets文件夹的内容会自动复制。Unity音频系统的差异编辑器和独立播放器的音频处理后端可能略有不同。尝试在Project Settings - Audio中将DSP Buffer Size设置为Best Latency以降低延迟并观察问题是否变化。sherpa-onnx版本不同版本的sherpa-onnx库可能存在行为差异。如果你遇到了类似“奇怪尾音”的问题可以尝试回退到已知稳定的版本如作者提到的1.10.13之前版本。更新到最新版本看问题是否已修复。检查sherpa-onnx的GitHub Issues看是否有类似报告。线程和内存管理确保在OnDestroy中正确释放TTS引擎 (_ttsEngine.Dispose())。流式播放中要管理好音频数据队列的生命周期避免内存泄漏。在场景切换或对象销毁时调用StopSpeaking()清理队列。5. 性能监控与高级调试技巧当一切就绪后我们还需要关注性能确保应用在各种设备上都能流畅运行。5.1 如何测量真实的合成延迟光靠感觉不行我们需要数据。可以在代码中添加简单的性能计时public void Speak(string text) { System.Diagnostics.Stopwatch sw System.Diagnostics.Stopwatch.StartNew(); // ... 清空队列等准备工作 ... // 在回调函数第一次收到数据时记录时间 // 修改 OnAudioGenerated添加一个标志位 if (!_firstChunkReceived) { _firstChunkReceived true; long firstAudioTimeMs sw.ElapsedMilliseconds; Debug.Log($首包音频延迟: {firstAudioTimeMs} ms); // 同时可以在这里通知主线程开始播放 MainThreadDispatcher.Enqueue(() StartAudioPlayback()); } // ... 其余代码 ... }这样你就能精确知道从调用Speak到收到第一个音频数据包用了多久。我的测试中在i7台式机上这个延迟通常在300-800毫秒之间取决于文本长度和模型复杂度。5.2 内存与CPU占用分析流式TTS是计算密集型任务。在Unity编辑器的Profiler窗口中你需要关注CPU Usage查看OfflineTts.GenerateWithCallback所在的线程通常是工作线程的CPU占用。如果持续过高如30%考虑优化NumThreads或寻找更轻量模型。GC Alloc关注每帧的GC分配。回调函数中new float[numSamples]和队列操作会产生托管内存分配。如果分配量很大可以考虑使用对象池来复用float数组但要注意线程安全。Audio Source确保OnAudioRead回调执行效率高不要有阻塞操作否则会导致音频断流或卡顿。5.3 处理长文本和中断在实际应用中用户可能打断当前的语音播报。我们的流式系统需要支持中断。public void StopSpeaking() { _isPlaying false; if (_audioSource.isPlaying) { _audioSource.Stop(); } lock (_queueLock) { _audioSampleQueue.Clear(); } _lastSamplePosition 0; // 重要我们需要一种方式来终止正在进行的合成任务。 // 遗憾的是sherpa-onnx的C# API目前没有提供直接的“取消”接口。 // 一种变通方法是在另一个线程中执行合成并设置一个取消标志。 // 当需要中断时设置标志位并忽略后续的所有回调数据。 _cancelToken true; // 假设有一个 volatile bool _cancelToken 变量 } // 在合成线程中 System.Threading.ThreadPool.QueueUserWorkItem(_ { _cancelToken false; try { _ttsEngine.GenerateWithCallback(text, speed: 1.0f, sid: speakerId, callback: (samples, n) { if (_cancelToken) return; // 如果已取消直接忽略数据 OnAudioGenerated(samples, n); }); } catch { /* 处理可能的异常 */ } });对于超长文本sherpa-onnx的MaxNumSentences参数可以控制单次处理的最大句子数。你可以将长文本按标点符号分割成多个短句依次合成和播放这样既能降低单次合成延迟也更容易实现中断功能。6. 面向移动端Android/iOS的特别注意事项如果你计划将应用发布到移动平台还需要额外注意以下几点库文件需要为Androidarm64-v8a, armeabi-v7a和iOSarm64准备对应的sherpa-onnx原生库.so或.a文件。这些通常需要从sherpa-onnx的源码针对各平台交叉编译。模型精度移动设备上建议使用量化模型INT8。量化模型体积更小推理速度更快功耗更低。sherpa-onnx的官方模型下载页通常同时提供FP32和INT8版本。将INT8版本的.onnx文件替换进去即可代码通常无需改动。性能调优移动端CPU能力有限务必设置config.Model.NumThreads 1。同时考虑在合成期间降低游戏其他部分的运算负荷比如降低画面质量或暂停一些后台计算。发热与耗电持续进行TTS合成是CPU密集型任务会导致设备发热和耗电增加。在设计交互时避免不必要的、频繁的语音合成。Android权限确保AndroidManifest.xml中包含了必要的权限如果从网络下载模型的话需要网络权限但离线合成通常不需要特殊权限。iOS后台播放如果希望应用在后台也能播放语音需要在Unity的Player Settings和Xcode工程中配置相应的音频后台模式。经过以上步骤你应该能在Unity项目中成功集成sherpa-onnx并实现一个延迟低、音质可接受的流式离线语音合成系统。这套方案特别适合需要快速语音反馈的交互式应用它能显著提升应用的响应感和沉浸感。