我在 StackOverflow 上读到,每次在 JavaSound 中播放剪辑时,它都会在幕后创建一个线程来播放它。如果这是真的(如果不是,请告诉我,因为我没有找到任何文档/源代码),这是否会被视为一个昂贵的调用,因为在任何 OS/JVM 中创建线程都是一项昂贵的任务?我还不确定,但我可能需要同时播放 10 到 20 个剪辑,所以我想知道这是否会成为问题。
PS:如果是创建线程之外的其他原因造成的过度调用,请告诉我。
我在 StackOverflow 上读到,每次在 JavaSound 中播放剪辑时,它都会在幕后创建一个线程来播放它。如果这是真的(如果不是,请告诉我,因为我没有找到任何文档/源代码),这是否会被视为一个昂贵的调用,因为在任何 OS/JVM 中创建线程都是一项昂贵的任务?我还不确定,但我可能需要同时播放 10 到 20 个剪辑,所以我想知道这是否会成为问题。
PS:如果是创建线程之外的其他原因造成的过度调用,请告诉我。
线程并不昂贵,尤其是。我亲自制作了一个运行超过 500 次的程序。服务器程序可以产生的数量远不止于此。
声音处理并不便宜,但我不知道它比许多图形效果(如 3D 照明)更占用 CPU 资源。我制作了一个程序,它既可以播放声音,又可以制作一个“发光球”,在播放声音时会逐渐变大和变暗。“发光球”不断更新 RadialGradientPaint 以实现此效果。我遇到了大约 10 个球和声音的天花板,而图形球是更大的处理负载。
不过,播放 17 Clips 时,您可能无法做很多其他事情。您必须对其进行测试,如果 cpu 跟不上,您会听到辍学的声音。
您的 17 个剪辑可能会占用大量 RAM。你知道它们都被加载到内存中,是吗?每秒 44100 个样本,通常每个样本 4 个字节(立体声,16 位 PCM),开始快速加起来。
因此,可能有理由考虑使用 SourceDataLine,尤其是对于较长的声音。
此外,某些操作系统似乎不能很好地处理多种声音。我在这里遇到了特别是 Linux 的问题。我最终编写了一个程序,将所有播放的声音混合到一个输出 SourceDataLine 中,作为一种处理方式。
另一种提高效率的方法是加载我自己定制的剪辑。我给这个 Clip 提供了多个光标(指针),它们可以独立地在音频数据中移动。这样,我可以多次(并且以不同的速度)重叠播放剪辑。要使用 Java Clip 执行此操作,您必须多次将其加载到 RAM 中。所以,你可以考虑写这样的东西。多个光标的输出可以通过 SourceDataLine 进行汇总和播放。