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