Re: [iiwusynth-devel] Fw: Re: [linux-audio-dev] more about iiwusynth

[Peter Hanappe]

Tim Goetze wrote:

> whatever you do for optimization, short fragment sizes are essential
> for professional work imo.

Short reply: I agree.

Long reply:

In fact, iiwusynth sends audio thru 3 different buffer sizes:

1) the audio driver uses an internal buffer size. Can be determined on
the command line.

2) the audio driver calls the synthesizer to fill a buffer. Can also be
set on the command line.

3) the synth uses internally a buffer of 64 samples.

The internal buffer serves two purposes. First, some drivers can call
the synthesizer to write a buffer of *any* length, even for a buffer
of 1 sample. This is the case for JACK and the DirectSound driver.
We can't run the dsp chain for one sample!
Second, using a fixed buffer size, known by the compiler can, help to
optimize the code (unrolling loops? Haven't tested if this really
works).

Also:

- I did some testing with various buffer sizes. When it was set to 32
and 16 samples, there clearly was an efficiency penalty. Using buffer
sizes larger than 64 samples did improve the efficiency a bit (in terms
of CPU-usage/buffer/buffersize) but it was not significant enough to
withhold them as a choice. See also next point.

- For low-latency applications, the common goal seems to be to use a 
buffer size for the driver of 3x64 samples.

- The jMax application has been using 64 samples internally for many
years now.

Cheers!
Peter


> tim