【发布时间】:2010-08-05 19:40:18
【问题描述】:
好的,我尝试了各种标题,但都失败了(所以如果有人想出更好的标题,请随时编辑:P)
我有以下问题:我正在使用 API 来访问我不编码的硬件,将库添加到我需要从 API 接口继承的 API,而 API 可以完成所有工作。
我把那个API,一个音乐生成器库,问题是提到的API只在缓冲区为空时调用音乐库,并要求硬编码的数据量(正好1024 * 16个样本......不知道为什么)。
这意味着音乐生成器库,无法使用所有 CPU 潜力,在播放音乐时,即使音乐库没有跟上,CPU 使用率仍然很低(如 3%),因此在部分音乐中,有太复杂的东西,缓冲区不足(即:声卡播放缓冲区中空的区域,因为音乐库函数还没有返回)。
调整硬编码的数字,只会使软件在某些机器上工作,而在其他机器上不工作,这取决于几个因素......
所以我想出了两个解决方案:用一些新的缓冲区逻辑来破解 API,但我没有想到这方面的任何东西。
或者我真正想到的逻辑:让音乐库有自己的线程,它将有自己的单独缓冲区,当 API 调用音乐库以获取更多数据时,它将一直填充,而不是生成时,它会将数据从单独的缓冲区复制到声卡缓冲区,然后继续生成音乐。
我的问题是虽然我有几年的编程经验,但我总是避免使用多线程,我什至不知道从哪里开始......
问题是:有人能找到另一个解决方案吗,或者指点我到一个地方,让我了解如何实施我的线程解决方案?
编辑:
我不是在阅读文件,而是在生成或计算音乐,明白吗?这不是 .wav 或 .ogg 库。这就是为什么我提到 CPU 时间,如果我可以使用 100% 的 CPU,我将永远不会出现欠载,但我只能在程序意识到缓冲区即将结束和实际结束之间的短时间内使用 CPU缓冲区,这个时间有时比程序计算音乐所用的时间少。
【问题讨论】:
-
每次 API 调用您的回调函数时,您是否从磁盘读取 (1024*16) 个字节?
-
@Hans 不重复,因为我不想要书,我有 2 天的时间来实现它:P 而且它并不复杂...... @tholomew 不,我正在生成 1024*16 字节,虽然当流式传输 .wav 文件时,API 确实从磁盘读取 1024*16 字节,但那部分与我无关......
标签: c++ multithreading buffering