Inertia's picture

[Audio] SoundData's internal buffer size

Project:The Open Toolkit library
Category:bug report


internal SoundData(SoundFormat format, byte[] data)
buffer = new byte[OpenTK.Functions.NextPowerOfTwo(data.Length)];

It should be

buffer = new byte[data.Length];


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Inertia's picture


Title:[Audio] SoundData's internal buffer is oversized.» [Audio] SoundData's internal buffer size
Status:open» confirmed
the Fiddler's picture


Status:confirmed» fixed

Fixed in rev. 1999.

Entropy's picture


Just occurred to me - using SoundData.ReadSamples(...) (iirc the name of the method) to read consecutive fixed-length sections of a .wav file and then queueing them with AL.QueueBuffers(...) produced a "popping" sound between each buffer (or just a buzz if the buffers were too short).

I dove into the OpenTK source a little while working on LinkSphere's MusicManager sub-project, but I didn't isolate the bug (which was already alluded to in an existing but commented-out example class bundled with the source). I got around it by directly handling the byte arrays in my in the Constructor for my Clip class. The key was making sure that the buffers were the same length as the clips being played.

The above fix should solve the problem with BufferData.ReadSamples(...), if it wasn't already fixed (haven't kept a close eye on the latest developments for a while).

If the existing audio examples still need any updating in mid-to-late August, I'll use/exercise what I learned writing the MusicManager to throw together some simple examples.

the Fiddler's picture


Status:fixed» closed

Closing bugs fixed in 0.9.8-2 and 0.9.9-1.

the Fiddler's picture


Version:0.9.x-dev» 0.9.9-1