[Audio] SoundData's internal buffer size
Posted Saturday, 18 July, 2009 - 15:25 by Inertia| Project: | The Open Toolkit library |
| Version: | 0.9.9-1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
SoundData.cs:
internal SoundData(SoundFormat format, byte[] data) ... buffer = new byte[OpenTK.Functions.NextPowerOfTwo(data.Length)];
It should be
buffer = new byte[data.Length];
Comments
#1
#2
Fixed in rev. 1999.
#3
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.
#4
Closing bugs fixed in 0.9.8-2 and 0.9.9-1.
#5