Each time I update the source I:

1. Clean the queue: alGetSourceiv with AL_BUFFERS_PROCESSED to get the number of finished buffers. If the number is greater than 0, I use alSourceUnqueueBuffers to get the buffer ID''s and pass them to alDeleteBuffers.


2. Get the buffer count: alGetSourceiv with AL_BUFFERS_QUEUED.


3. If the buffer count is less than the minimum: I load and queue more buffers.


4. If the buffer count was 0 (there was a pause in the play back since we weren''t quick enough, this hopefully shouldn''t happen): I make sure to play the source again

how much space would it take up if say, a 5 minute ogg were loaded all at once?

heh, this may be a cheap way of getting it done, but its really nice because you can customize the number of buffers waiting in the queue VERY easily, and as far as i can tell, its as fast as it can be:

	ALuint temp;	alSourceUnqueueBuffers(Source, 1, &temp);	LoadNextBuffer(temp); 

it checks to see if there is a buffer in the processed queue, after its been played. the second its been played, it passes the handle to the load next buffer function which fills it again with the next set of data and pops it on the queue again

just out of curiosity, what buffer size do you use? i''m using 65536, seems to work ok. i guessed thats what one second was since its 16 bit.

quote: Original post by billybob
how much space would it take up if say, a 5 minute ogg were loaded all at once?

It depends on the size, the frequency, and the number of channels. A five minute (300 second) ogg vorbis file with two channels, with a frequency of 44100, and a sample size of 16 bits (2 bytes) would be 52,920,000 bytes (~50.4 MB) fully decoded.

quote: Original post by billybob
just out of curiosity, what buffer size do you use? i''m using 65536, seems to work ok. i guessed thats what one second was since its 16 bit.

I''m still experimenting with what size I''ll use, but for now I''m using 4096 bytes (4 KB). Lowering has some advantages (lower latency in certain situations), raising it has others (less chance of playback stuttering).

oh wow, i''m way to high then. my el-cheapo method of getting buffers back on queue might make it easier for lots of smaller buffers, i''ll try it out.

ya, if i use 2048 buffers with 10 buffers, i get no stutter, and with 20 i get no difference with 65536. i really like this method. i thought it was a crappy shortcut i would have to redo later on

next up: a thread to take away the need to call update.

do you know if you call alBufferData() on a buffer that already has data, if it will cause a memory leak? or if it will overwrite the old data? or if it will just delete the old data, and fill it with the new data? when my ogg is playing, memory doesn''t go up in the task manager, so i don''t think it causes a memory leak. the way my player works is that it just does alBufferData on the same buffer from the alUnqueueBuffers() function. so if alBufferData doesn''t somehow get rid of the old buffer (deleting, overwriting, whatever) i think it may cause memory leaks.

I took a look at the source code to make sure, and alBufferData appears to free any memory the buffer is using.

the source? THE SOURCE. i forgot it has the source included, sorry for that dumb question.

arggghh wtf. i'm having massive difficulty looping. it works on MOST songs, but there are a few where it just REFUSES to loop. i think it might be because they are unseekable (thats how i start over), but they are files, so i don't see how thats possible.

edit: after tons and tons of testing, its apparently just this ONE song that can't loop for some reason. i guess i'll use the callbacks and play from memory to get away from a few ogg files' unseekability.

[edited by - billybob on December 30, 2002 4:54:21 AM]