I’m associating sounds with the collisions of objects bouncing around in a space. I need to set the volume and balance for each occurrence of the sound based on where the collision occurred. I’ve chosen to do this by hand (as opposed to using the native 3d audio support in Panda3d) because the calculations may be pretty simple; doppler shift, etc. is more functionality than I need, and i’m using an unusual speaker configuration and I need direct control of the levels for each one.
I know that in order to control the volume of different instances of the same sound, I must create a number of pooled instances of AudioSound objects. This is done easily enough by calling .loadSfx() repeatedly.
The problem is that by default, PandaLoader.loadSfx() gives me AudioSound objects which have duplicate copies of the actual audio data. There’s no need for the (potentially large) sound bytes to be redundant like that, so I’d like to know if there’s a way to create AudioSound objects which reference a shared memory space.
Are you sure? I don’t know about the Fmod implementation (which is distributed with the public Panda3D downloadable version), but with the Miles sound implementation (which is what we use in the VR Studio), each call to loadSfx() returns a new AudioSound object, but with its internal memory shared with all other AudioSound objects that were loaded from the same file. So that any given sound file is loaded into memory only once, no matter how many times loadSfx() is called, or how many different AudioSound objects are created from it. I would assume that the Fmod implementation behaves similarly.
You could test this, of course, by loading up hundreds or thousands of copies of a particular sound file, and seeing how much more your memory usage bloats from just loading up one copy.
I did run that test before posting, yeah. I created a 30-second .wav file which was about 2.5 mB, and then fired up the python interpreter directly.
Here’s my test:
start task manager
start python: it uses 3204 K
from pandac.PandaModules import import Audiosound: 24396K used
import direct.directbase.DirectStart: 39320K used
s = loader.loadSfx( “tone.wav” ) : 41936K used
s2 = loader.loadSfx( “tone.wav” ) : 44528K used
sounds = [loader.loadSfx( “tone.wav” ) for i in range( 10 ) ] : 70504K used
del sounds : 44572K
del s2 : 41984K
del s : 39388K
So of course my test could be invalid for some reason, or it could be our build; I’m using the Schell Games internal build which recently integrated the sound work done by the ETC Panda3d class this last semester. So it should be using Fmod 4, but I’m not sure if/how that impacts the initialization of AudioSound.
In my own duplication of your experiment, using our VR Studio build which uses Miles, I observed the following:
start task manager
start python: it uses 3212 K
from pandac.PandaModules import AudioSound: 25500K used
import direct.directbase.DirectStart: 34456K used
s = loader.loadSfx(“tone.wav”) : 34460K used
s2 = loader.loadSfx(“tone.wav”) : 34460K used
sounds = [loader.loadSfx(“tone.wav”) for i in range( 10 ) ] : 34464K used
7a. sounds = [loader.loadSfx(“tone.wav”) for i in range( 100 ) ] : 34464K used
7b. sounds = [loader.loadSfx(“tone.wav”) for i in range( 1000 ) ] : 34488K used
del sounds : 34488K
del s2 : 34488K
del s : 34488K
The small growth when allocating larger arrays for sounds is consistent with allocating space for the Python objects. Also, it is likely that the system space for Python objects is not immediately released when the objects are deleted, which explains why my memory did not go down when releasing these things.
So it appears that the Fmod implementation does not share memory in the same way that the Miles implementation does. This is the responsibility of the interface layer for each implementation. Maybe Josh can speak to the possibility of improving the Fmod interface layer to do this kind of sharing? I’m not sure whether it impacts the 3D functionality or not (which is presently supposed only by the Fmod implementation).
Like I said, I don’t think actual 3d support is going to be very important to me. Also, this issue shouldn’t be a really big deal because the sounds I’m pooling will tend to be short, which means my pools can be small anyway. Obviously we’ll want to see it fixed, but it’s not a showstopper or anything.