Hi,

  ALuint bf;
  ALuint src;

  int size;
  short* data;
  int sampling_rate;

  size = maximum - minimum;
  data = new short[maximum - minimum];
  data = (short*)memcpy(data, &GetData()[minimum], size);
  sampling_rate = GetSamplingRate();

  alGenBuffers(1, &bf);
  alBufferData(bf, AL_FORMAT_STEREO16, data, size * 2, sampling_rate);
  alGenSources(1, &src);
  alSourcei(src, AL_BUFFER, bf);

  alSourcePlay(src);

 

This is a piece of code that is periodically called after a certain period of time (buffer length) until the entire track is played back. I'm using a thread to create the buffer cycle. The problem here is that when short* GetData() which returns the actual data, is played back entirely, everything is fine, but as soon as I start chopping it up, the sound becomes all messed up. I've been over and over it this time - this is the skeleton code to which I've hewn it down to: playback is 1) incontiguous - the waveform is severed at places, parts of it are skipped and parts of it are played at the wrong time (eg the beginning is played again in the middle, etc.). I'm sure I'll have to admit the fault here is mine, but I cannot see it. minimum and maximum define the byte offsets where the buffer is to begin and end in the main data block. Is &GetData()[minimum] the correct way to copy data from index ? I've tried using various buffer sizes from 25 to 3000 ms - the bigger they are the better the playback results, but I'd like to get it working within the range of 10 to 500 ms. Does anyone have any clues as to what I might be doing wrong? If necessary I'll post more code - the only problem is that there's not too few of it Thanks in advance, Crispy [edited by - crispy on June 3, 2002 6:27:12 PM]

If this is the same problem I once had, then I have some answers (or, at least info):

If you''re using OpenAL in Windows, make sure that you don''t ever try to play a buffer that''s already playing (very bad sound corruption). This doesn''t seem to affect non-Windows implementations. This probably isn''t your problem, but it can''t hurt to tell you.

Another problem I only had with OpenAL in Windows: try to use buffers that are at least 4 KB. I never got OpenAL to allow me to seamlessly stream audio with samples less than 4 KB in Windows without so popping at the seams. I don''t know much about DirectSound, so I never went looking for the cause in the OpenAL source, but you can if you''d like . This is another issue I haven''t had outside of the Windows DirectSound implementation.

If you''re trying to stream audio, learn how to ''queue'' buffers to a source, it helps a lot. I have done streaming audio in OpenAL with no problems in Windows and Linux, so it''s very possible .

Thanks Null and Void

Would you, however mind telling me how you wrote your buffered playback code? Did you use 2 sources and played them back in turns just as I tried or only one source, creating it over and over again every time you played it? If you have some code you wouldn't mind posting I'd really appreciate it - I'm creating a new buffer and a new source every time I start the playback, so they couldn't possobly overlap, the buffer size I'm using is well over 20kB and I can't think of a way how to queue buffers if I only have 1 or 2 sources and only 1 contiguous data source (I mean - what's the point?)

Crispy

[edited by - crispy on June 4, 2002 4:36:38 AM]

I use one source with up to 10 buffers queued at a time (my buffers are 4 KB by default, since that''s the ''magic number'' to get around the Windows issues). I run an updater in a seperate thread, and each time the buffers queued go below the number I chose (10 by default, because it keeps extras for high CPU usage periods, I wanted to be careufl) I start loading more buffers and queuing them to the source.

Okay...

the buffering works, but obviously something else doesn't. Null and Void, how do you write data into the buffers? The way I do it results in messed up buffers - I can't even make out what happens to them...

Here's how I'm doing it currently:


alBufferData(buffer[i], AL_FORMAT_STEREO16, data16 + i * 12000, 12000, 44100);


which should be the same as:


alBufferData(buffer[i], AL_FORMAT_STEREO16, &data16[i * 12000], 12000, 44100);


(i is the loop iterator)

right? If do not increment the pointer address (copy data into all of the buffers from data16[0] to data16[12000]), the buffers seem to be copied correctly (at least they sound the way they should), if I do, however, they're messed up, so my guess is that the addressing is wrong...

Crispy


[edited by - crispy on June 4, 2002 7:49:54 AM]

I can''t really say what your problem is just from that, since it looks okay to me. If you want, I can put the code from my audio system online somewhere.

quote: Original post by Null and Void
If you want, I can put the code from my audio system online somewhere.

I''d really apprecite that.

Crispy

There might be a thread issue in my Ogg Vorbis code (I haven''t confirmed if there is one or, if there is, where it is), so be careful of copying my multithreaded stuff too closesly (if you do see a deadlock issue, tell me ). The code uses stuff from the rest of the engine, but I think you can figure out how that works. I deleted the Aiff loader a while back, since it didn''t work correctly and I want to redo it someday. Here''s the link: http://omapi.sf.net/gtw/gtwaudio.tar.gz

Thanks Null and Void! I figured it out with the help of your code - you have to pass in twice the amount of data when you''re playing back a 16-bit audio source

I must compliment you on your unnaturally beautiful coding style - very easy to read (if to overlook the fact that I''m used to positioning braces a bit differently). Just to make a note of - I try, whenever possible, to defer copy-pasting code that is not my own - I, however, thank for not hesitating in letting me use it (which I didn''t for purposes other than to find the flaw in my own code).

PS - so far I haven''t been able to spot any deadlocks or pieces of bad code - if there are any, they''re elsewhere, imo.

Crispy

quote: Original post by Crispy
I must compliment you on your unnaturally beautiful coding style - very easy to read (if to overlook the fact that I''m used to positioning braces a bit differently).

It''s mostly a habit from the time I spent reading books that used K&R style formatting . I''ve grown used to the space it saves, so I can''t easily switch to other formatting styles.