# Confused about my buffer size...

11 replies to this topic

### #1threeam

New Member

• Members
• 11 posts

Posted 26 February 2007 - 05:33 PM

I might or might not be confused about why the size of my buffer has to be the way it is in order for my application to work. So I'll explain everything I'm thinking and you guys can tell me if I'm on the right track and/or explain it to me better. Pardon if this seems a little messy, I wrote it as if I was "thinking on paper."

BUF = 2048
mybuf[BUF*11]
my sample rate is 44100hz, stereo (16bit / 2 channel)

My application won't work with anything below 11, happens to be that BUF * 11 ~ (44100/2)!

It seems like the buffer has to be > (44100 / 2) ?Nyquist–Shannon sampling theorem? I'm thinking I'm not actually sampling at 44100, but at half. (I don't think that's why though... ok new direction...)

44100*2(channels)*2(16bit)=176400 byte array... right? well... then I thought then that int32 bit value ~ 176400/4(32bit) = 44100 int32 bytes....

So then this popped in to my mind... the above could work IF you store a 16 bit value in to a 32 bit integer you get half the space used!

So 44100 / 2 = 21050 which is ~ BUF*11 which is what I need MIN for my app to work.

So did I understand this correctly? Or did I say something completely stupid?

### #2SamuraiCrow

Senior Member

• Members
• 459 posts

Posted 26 February 2007 - 05:53 PM

Buffer sizes are often a point of experimentation. It depends on how much processor time/memory bandwidth is available.

### #3Reedbeta

DevMaster Staff

• 5305 posts
• LocationBellevue, WA

Posted 26 February 2007 - 06:01 PM

The calculation you made seems to assume the buffer has to hold at least one second of audio. There's no reason though why buffers of less than one second shouldn't be possible.

What do you mean when you say your application won't work with too small a buffer size?
reedbeta.com - developer blog, OpenGL demos, and other projects

### #4threeam

New Member

• Members
• 11 posts

Posted 26 February 2007 - 06:04 PM

No one should have to 'experiment' to determine an appropriate buffer size for an audio sample, especially on a computer with known variables. Not to mention my application works with the above settings on -various- systems with fairly varied specs.

It's not per second, it's per 1/1000th a second. My buffer is continuously filled and emptied, meaning that whether it's per second or not is irrelevant since at -any- time interval possible i deal with BUF*11 amount of data. And I'm trying to discover why BUF*11. I hope that clarifies my intent.

My application draws an oscilloscope and the spectrum analysis for each sample through openGL.

But that's regardless, as my concern is in discovering the reason for the buffer size at all. (~44100/2)

If I don't use BUF*11 minimum the application simply fails.

### #5Reedbeta

DevMaster Staff

• 5305 posts
• LocationBellevue, WA

Posted 26 February 2007 - 06:22 PM

threeam said:

No one should have to 'experiment' to determine an appropriate buffer size for an audio sample, especially on a computer with known variables. Not to mention my application works with the above settings on -various- systems with fairly varied specs.

Experimentation is a completely valid method of finding an optimal buffer size. No one can calculate what the best buffer size should be in the presence of all the myriad bandwidths and latencies of a modern computer with many hardware details undocumented.

Quote

whether it's per second or not is irrelevant since at -any- time interval possible i deal with BUF*11 amount of data. And I'm trying to discover why BUF*11.

The length of the buffer is still a time interval; it's irrelevant whether you are continually filling and emptying that buffer or not. I'm not sure what you mean by your comments about per second vs per millisecond.

If your buffer is storing PCM wave data at 44.1 kHz, 16 bits/sample, 2 channels, then the data rate is 176400 bytes/second and a buffer of 2048*11 = 22528 bytes would hold 0.128 seconds of audio. However you haven't said what data type the buffer is; if it's rather 2048*11 32-bit words then you have 0.511 seconds of audio...unless you are expanding each 16-bit sample to 32 bits for processing, in which case only 0.255 seconds. *shrug*

Quote

If I don't use BUF*11 minimum the application simply fails.

What do you mean by "simply fails"? That's no more descriptive than "won't work".
reedbeta.com - developer blog, OpenGL demos, and other projects

### #6threeam

New Member

• Members
• 11 posts

Posted 26 February 2007 - 06:24 PM

Program closes, the moment it opens.

this is what i was thinking:
------Int32------
16bit L | 16bit R
-----------------

### #7threeam

New Member

• Members
• 11 posts

Posted 26 February 2007 - 06:39 PM

I just want to know if the math I did corresponds to something real and if it's why the value's I have to use are explained by that. If the entire notion of what I'm seeking is insane, then tell me that and explain to me my fallacy so I can better understand this science.

Thanks...

### #8SamuraiCrow

Senior Member

• Members
• 459 posts

Posted 26 February 2007 - 06:46 PM

If you are using SDL_mixer or any other open-source sound player you can look at the source code and find out for yourself.

I think you need to tell us more about your program if you want to find out why it's crashing if you set the buffer too small. Normally it just gets too choppy when the buffer is too small.

Normally the left and right side are stored like you said, side-by-side in a 32-bit integer. The endianness comes into play if you are concerned about that (depends on the file format and processor type you are using).

### #9threeam

New Member

• Members
• 11 posts

Posted 26 February 2007 - 06:52 PM

I'm writing an OpenAL/OpenGL application. Here is the essential parts of the application for capturing audio... when BUF*11 any lower the application simply does not run.

#include <AL/al.h>
#include <AL/alc.h>

#define BUF 2048
ALCdevice *mydevice;
ALbyte mybuf[BUF*11];
ALint samples;

// ... in main
alGetError();
mydevice = alcCaptureOpenDevice(NULL, 44100, AL_FORMAT_STEREO16, BUF);
if (alGetError() != AL_NO_ERROR)
{
return 0;
}
alcCaptureStart(mydevice);

// ... in a loop with sleep(1) -> draw spectrum / fft based on mybuf data
alcGetIntegerv(mydevice, ALC_CAPTURE_SAMPLES, (ALCsizei)sizeof(ALint), &samples);
alcCaptureSamples(mydevice, (ALCvoid *)mybuf, samples);

// ... on exit in main
alcCaptureStop(mydevice);
alcCaptureCloseDevice(mydevice);



### #10SamuraiCrow

Senior Member

• Members
• 459 posts

Posted 26 February 2007 - 07:12 PM

Ah, you're reading in from a sampler? It makes sense that a buffer overrun would cause a crash. The more often you read in, the less of a buffer you should need.

### #11threeam

New Member

• Members
• 11 posts

Posted 26 February 2007 - 07:17 PM

So is it logical to conclude that my buffer size (int32) for any given sample must be larger than half the sample rate (hz) for 16bit stereo?

I want to be able to use the optimal size for my buffer, no more than -necessary-.

### #12Reedbeta

DevMaster Staff

• 5305 posts
• LocationBellevue, WA

Posted 26 February 2007 - 08:35 PM

threeam said:

So is it logical to conclude that my buffer size (int32) for any given sample must be larger than half the sample rate (hz) for 16bit stereo?

No, that's not logical. As SamuraiCrow pointed out you should be able to use a smaller buffer if you capture samples more often. I would recommend that you check the return codes from each OpenAL function you call; if one of them gives an error code that may help you pinpoint the problem.
reedbeta.com - developer blog, OpenGL demos, and other projects

#### 1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users