使用音频播放时，我习惯了以下模式：
这样可以正常使用，例如，使用WAV文件时没有问题。
现在，如果源数据以压缩格式编码，如Vorbis或MP3，则解码需要一些时间。
在磁盘/网络线程中执行解码似乎很常见。
但这不是错误的设计吗？在磁盘或网络访问块时，某些CPU时间可用于解码，但如果在同一线程中发生解码则会浪费。
在我看来，如果网络变慢，那么如果按顺序进行解码，则缓冲区欠载的风险会更高。
那么，不应该在音频线程中执行解码吗？
在我的上下文中，我宁愿避免添加专用的解码线程。它适用于移动平台，SMP现在非常罕见。但请告诉我们一个专用的解码线程是否真的对你有意义。
答案 0 :(得分：2)
音频线程可以平滑播放音频比网络线程更重要，以保持完美的大小缓冲区。如果您只使用两个线程，那么解码应该在网络线程上完成。如果您要在播放线程上进行解码，则可能需要将更多音频输出到硬件但线程正忙于解码的时间。如果你保留已解码音频的缓冲区，那就更好了。
理想情况下，您将使用三个线程。一个用于读取网络，一个用于解码，一个用于播放。在我们处理音频/视频捕获，录制和流媒体的应用程序中，我们每个流有8个线程（最近从我们最近添加新功能以来的六个线程增加了）。每个线程都更容易拥有它自己的功能，然后它可以适当地测量其性能与其传入/传出缓冲区的性能。这也有利于分析和优化。
答案 1 :(得分：2)
如果您的设备只有一个CPU，则所有线程都在共享它。操作系统线程交换通常非常有效（交换时不会丢失任何有意义的CPU功率）。因此，如果它将简化您的逻辑，您应该创建更多线程。
在您的情况下，有一个管道。管道的每个阶段的不同线程是一个很好的模式。正如您所注意到的，备选方案涉及复杂的逻辑，同步，事件，中断等等。有时根本没有好的选择。
因此，我的建议 - 为音频解码创建专用线程。
如果您拥有多个CPU，那么通过为每个管道步骤使用一个线程，您甚至可以获得更高的效率。