Re: Question about distributing modifications to open-al

On Thursday, October 20, 2011 8:56:53 AM Robert McIntyre wrote:
> I'm working on an AI simulation involving multiple listeners, where
> each listener is a separate AI entity.  Since each AI entity can move
> independently, I needed to add multiple listener functionality to
> open-al. Furthermore, my entire simulation allows time to dilate
> depending on how hard the entities are collectively "thinking," so
> that the entities can keep up with the simulation.  Therefore, I
> needed to have a system that renders sound on-demand instead of trying
> to render in real time as open-al does.

FWIW, newer Git versions of OpenAL Soft have preliminary code that allows you 
to render to a memory buffer on-demand (the ALC_SOFT_loopback_device stuff; 
check in alMain.h for the functions and enums). Some of it's still subject to 
change, but perhaps it'd be easier to work off of that.

> The options I have thought of so far are:
> 
> 1.) Create my own C-artifact, compiled against open-al, which somehow
> "hooks in" my device to open-al and forces open-al to use it to the
> exclusion of all other devices.  This new artifact would have bindings
> for java, etc.  I don't know how to do this, since there doesn't seem
> to be any way to access the list of devices in Alc/ALc.c for example.
> In order to add a new device to open-al I had to modify 5 separate
> files, documented here:
> 
> http://aurellem.localhost/audio-send/html/add-new-device.html
> 
> and there doesn't seem to be a way to get the same effect
> programmatically.

OpenAL Soft doesn't support plugin modules for device backends, because the 
internals change too often for them to work for more than a version or two.

> 2.) Strip down open-al to a minimal version that only has my device
> and deal with selecting the right open-al library at a higher level,
> depending on whether the user wants to record sound or actually hear
> it.  I don't like this because I can't easily benefit from
> improvements in the main open-al distribution. It also would involve
> more significant modification to jMonkeyEngine3's logic which selects
> the appropriate C-artifact at runtime.

Unfortunately, what it looks like the code tries to do probably wouldn't be 
very future-proof, anyway. Changes in OpenAL Soft could break some of the 
assumptions your device makes when synchronizing objects.

> 4.) Maybe abandon the device metaphor and use something better suited
> to my problem that /can/ be done as in (1)?

If I'm understanding right, you're trying to make a single sound play multiple 
times, just with multiple listener reference points, correct? If that's the 
case, then the loopback device could help solve your problems without source 
changes.

What you can try is: open a loopback device (alcLoopbackOpenDeviceSOFT), 
create two contexts from it (alcCreateContext twice; make sure to pass the 
ALC_FORMAT_CHANNELS_SOFT and ALC_FORMAT_TYPE_SOFT attributes with the 
appropriate enum values, along with ALC_FREQUENCY and the appropriate sample 
rate, which will affect the output of the whole device), and use those 
contexts "normally". For every sound source you need, generate 1 source on 
both contexts (make one context current, generate a source, make the other 
context current, generate another source). Whenever you change one source, 
make sure to change the source on the other context, too.

No processing will occur until you call alcRenderSamplesSOFT, so you don't 
need to worry about one source being updated without the other, and it will 
process all contexts on the device simultaneously. Time only moves when 
rendering samples, so it'll go as fast or as slow as you want.

Buffers are also shared between contexts on the same device, so the buffer can 
be created/loaded once and the two sources can use the same buffer.

The only downside is the loopback extension isn't yet finished, and there 
could be some (minor, but potentially incompatible) changes before it is.

I hope that's clear. If not, feel free to ask for clarification. :)
_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal