Question about distributing modifications to open-al

My name is Robert McIntyre. I am seeking help packaging some changes
I've made to open-al.

* tl;dr how do I distribute changes to open-al which involve adding a
  new device?

* Background / Motivation

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.

I don't need any of the more advanced effects, just 3D positioning,
and I'm only using open-al from jMonkeyEngine3 that uses the LWJGL
bindings that importantly only allow access to one and only one
context.

Under these constraints, I made a new device which renders sound in
small, user-defined increments.  It must be explicitly told to render
sound or it won't do anything.  It maintains a separate "auxiliary
context" for every additional listener, and syncs the sources from the
LWJGL context whenever it is about to render samples.  I've tested it
and it works quite well for my purposes.  So far, I've gotten 1,000
separate listeners to work in a single simulation easily.

The code is here:
http://aurellem.localhost/audio-send/html/send.html
No criticism is too harsh!

Note that the java JNI bindings that are part of the device code right
now would be moved to a separate file the the same way that LWJGL does
it. I left them there for now to show how the device might be used.

Although I made this for my own AI work, it's ideal for recording
perfect audio from a video game to create trailers/demos, since the
computer doesn't have to try to record the sound in real time.  This
device could be used to record audio in any system that wraps open-al
and only exposes one context, which is what many wrappers do.


* Actual Question

My question is about packaging --- how do you recommend I distribute
my new device?  I got it to work by just grafting it on the open-al's
primitive object system, but this requires quite a few changes to main
open-al source files, and as far as I can tell requires me to
recompile open-al against my new device.

I also don't want the user to be able to hide my devices presence
using their ~/.alsoftrc file, since that gets in the way of easy
recording when the system is wrapped several layers deep, and they've
already implicitly requested my device anyway by using my code in the
first place.

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.

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.

3.) Get this new device added to open-al, and provide a java wrapper
for it in a separate artifact. Problem here is that this device does
not have the same semantics as the other devices --- it must be told
to render sound, doesn't support multiple user-created contexts, and
it exposes extra functions for retrieving the rendered sounds. It also
might be too "niche" for open-al proper.

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


I'm sure someone here knows enough about open-al's devices to give me
a better solution than these 4!  All help would be most appreciated.

sincerely,
--Robert McIntyre

_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal