我正在用 java 设计一个音频架构。我知道我知道，我应该使用 c++...
无论如何，我已经阅读了 Craig Lindleys 的 Java 数字音频一书。他描述了一种拉式架构，其中设备以链表的形式连接，并且接收设备从紧接在它之前的设备请求数据。该设备调用相同的接口方法从之前的设备获取数据。该方法类似于：
public int getSamples(byte[] data);
我很想看看其他人对此有何看法。 c++，java，随便。可以在某种程度上详细说明诸如 pro tools、ableton 和 reason 之类的架构。这些系统是否完全依赖于类似于 Lindley 所描述的“拉式架构”，尽管它更成熟。
请原谅这个问题的广泛性。
【问题讨论】：
标签： java c++ design-patterns audio architecture
我见过基于推拉的音频架构，它们各有利弊。
在基于推送的系统中，每个过滤器都将数据向下游推送到下游过滤器，您需要一些定时推送请求的概念，以便在声卡准备好时在音频处理单元链的末端拥有数据为数据。这通常以外部时钟的形式出现，它会定时抽水。 DirectShow 以这种方式工作。
在基于拉的系统中，您可以使用来自声卡的 I/O 请求来驱动图形的泵送，从而让您的设备运行时钟。在这个系统中，您仍然需要在图表（数据源）的开头进行缓冲。
我建议不要做一个基于拉/推的系统，而是一个执行器风格的架构。想象一下，您有一组由 AudioGraph 对象管理的音频处理单元 (APU)，该对象知道它们是如何连接的。现在，您可以使用声卡中的音频回调，并将任何音频输入传递给您的 AudioGraph，并让 AudioGraph 通过每个音频处理单元管理处理数据。这将数据流与 I/O 请求完全分开，并允许您的 AudioGraph 进行诸如并行处理请求、运行请求以处理每个过滤器乱序等。此外，每个 APU 不需要了解其邻居并且它们仅在 AudioGraph 级别“连接在一起”。这是 OS X 上的 AudioUnits。
【讨论】：