Home/ Questions/Q 7170043
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T15:07:55+00:00

I am designing an audio architecture in java. I know I know, I should

  • 0

I am designing an audio architecture in java. I know I know, I should be using c++…

Anyway, Ive read Craig Lindleys book Digital Audio with java. He describes a pull architecture where devices are connected in a linked list and the sink devices requests data from the the device immediately prior to it. That devices calls the same interface method to get the data from the device prior to it. The method is something like:

public int getSamples(byte[] data);

I am interested to see what other people think of this. c++, java, whatever. can somewhat elaborate on the architecture of something like pro tools, ableton, and reason. Do those systems at all rely on a “pull architecture” similar to what Lindley describes albeit more mature.

Forgive the broad nature of the question.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ve seen audio architectures that are push and pull based, and both have pro’s and cons.

    In a push based system where each filter pushes data downstream to a down stream filter, you need some notion of timing the push requests such that you have data at the end of your chain of audio processing units when the sound card is ready for data. This usually comes in the form of an external clock which times pumping of your graph. DirectShow works this way.

    In a pull based system you can use the I/O requests from the soundcard to drive pumping of the graph, which lets the clocking be run by your device. In this system you will still need buffering at the start of your graph (data sources).

    I would recommend not doing a pull/push based system, but an executor style architecture. Imagine that you have a set of audio processing units (APU) which are managed by an AudioGraph object, who knows how they are connected. Now, You can use the audio callbacks from the soundcard, and pass any audio inputs to your AudioGraph, and let the AudioGraph manage processing data through each of the audio processing units. This separates the data flow completely from the I/O requests, and allows your AudioGraph to things like parallelize processing requets, run requets to process each of the filters out of order, etc. Also each APU doesn’t need to know about its neighbors and they are only “connected together” at the AudioGraph level. This is AudioUnits on OS X works.

    • 0