Designing Sound

Buffering
To avoid this timing mess we use buffers. You will often see controls for your
sound card or audio programs that allow you to adjust the buffer settings. A
buffer is like a queue of things called
blocks
that the supplying program puts
at one end and the consuming program or device takes off the other. To reduce
the number of times this has to happen it’s better that each block contains
more than one sample, so each program can operate on a bunch of samples at
a time. A typical choice of block size is 64 samples. So long as the buffer is
reasonably full both programs can go about their business in their own time.
If the buffer gets too empty then the sound card can tell the sound-generating
program to make more blocks. If the buffer gets too full then the sound card
can ask it to slow down. So long as the buffer has something in it the DAC

---

7.3 Generating Digital Waveforms
129
will have something to do. To ask the generating program for another block the
sound card
calls a function
. This
call back
function fills up a block with new
data and passes it back, where it gets appended to the end of the buffer.
void
f i l l b l o c k ( )
{
i n t
sa mple = 6 3 ;
f l o a t
b l o c k [ 6 4 ] ;
while
( sample
−−
)
{
b l o c k [ sa mple ] = 0 . 0 ;
}
}
In the pseudo code
3
snippet above our call back function is called
fillblock()
,
which stuffs an array of 64 floating point numbers with zeros. The current sam-
ple is decremented on each pass through the loop and the loop exits when
sample
is zero. The only thing that can go wrong is if the generating program
is so busy it cannot supply new blocks in time. Then we get stutters, clicks,
and dropouts as the DAC starves and stops outputting any audio.