Inertia's picture

[Audio] SoundData's internal buffer size

Project:The Open Toolkit library
Version:0.9.9-1
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed
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

Comment viewing options

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

#1

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

#2

Status:confirmed» fixed

Fixed in rev. 1999.

Entropy's picture

#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.

the Fiddler's picture

#4

Status:fixed» closed

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

the Fiddler's picture

#5

Version:0.9.x-dev» 0.9.9-1