rlm@0: My name is Robert McIntyre. I am seeking help packaging some changes
rlm@0: I've made to open-al.
rlm@0: 
rlm@0: * tl;dr how do I distribute changes to open-al which involve adding a
rlm@0:   new device?
rlm@0: 
rlm@0: * Background / Motivation
rlm@0: 
rlm@0: I'm working on an AI simulation involving multiple listeners, where
rlm@0: each listener is a separate AI entity.  Since each AI entity can move
rlm@0: independently, I needed to add multiple listener functionality to
rlm@0: open-al. Furthermore, my entire simulation allows time to dilate
rlm@0: depending on how hard the entities are collectively "thinking," so
rlm@0: that the entities can keep up with the simulation.  Therefore, I
rlm@0: needed to have a system that renders sound on-demand instead of trying
rlm@0: to render in real time as open-al does. 
rlm@0: 
rlm@0: I don't need any of the more advanced effects, just 3D positioning,
rlm@0: and I'm only using open-al from jMonkeyEngine3 that uses the LWJGL
rlm@0: bindings that importantly only allow access to one and only one
rlm@0: context.
rlm@0: 
rlm@0: Under these constraints, I made a new device which renders sound in
rlm@0: small, user-defined increments.  It must be explicitly told to render
rlm@0: sound or it won't do anything.  It maintains a separate "auxiliary
rlm@0: context" for every additional listener, and syncs the sources from the
rlm@0: LWJGL context whenever it is about to render samples.  I've tested it
rlm@0: and it works quite well for my purposes.  So far, I've gotten 1,000
rlm@0: separate listeners to work in a single simulation easily.
rlm@0: 
rlm@0: The code is here: 
rlm@0: http://aurellem.localhost/audio-send/html/send.html
rlm@0: No criticism is too harsh! 
rlm@0: 
rlm@0: Note that the java JNI bindings that are part of the device code right
rlm@0: now would be moved to a separate file the the same way that LWJGL does
rlm@0: it. I left them there for now to show how the device might be used.
rlm@0: 
rlm@0: Although I made this for my own AI work, it's ideal for recording
rlm@0: perfect audio from a video game to create trailers/demos, since the
rlm@0: computer doesn't have to try to record the sound in real time.  This
rlm@0: device could be used to record audio in any system that wraps open-al
rlm@0: and only exposes one context, which is what many wrappers do.
rlm@0: 
rlm@0: 
rlm@0: * Actual Question
rlm@0: 
rlm@0: My question is about packaging --- how do you recommend I distribute
rlm@0: my new device?  I got it to work by just grafting it on the open-al's
rlm@0: primitive object system, but this requires quite a few changes to main
rlm@0: open-al source files, and as far as I can tell requires me to
rlm@0: recompile open-al against my new device. 
rlm@0: 
rlm@0: I also don't want the user to be able to hide my devices presence
rlm@0: using their ~/.alsoftrc file, since that gets in the way of easy
rlm@0: recording when the system is wrapped several layers deep, and they've
rlm@0: already implicitly requested my device anyway by using my code in the
rlm@0: first place.
rlm@0: 
rlm@0: The options I have thought of so far are:
rlm@0: 
rlm@0: 1.) Create my own C-artifact, compiled against open-al, which somehow
rlm@0: "hooks in" my device to open-al and forces open-al to use it to the
rlm@0: exclusion of all other devices.  This new artifact would have bindings
rlm@0: for java, etc.  I don't know how to do this, since there doesn't seem
rlm@0: to be any way to access the list of devices in Alc/ALc.c for example.
rlm@0: In order to add a new device to open-al I had to modify 5 separate
rlm@0: files, documented here:
rlm@0: 
rlm@0: http://aurellem.localhost/audio-send/html/add-new-device.html
rlm@0: 
rlm@0: and there doesn't seem to be a way to get the same effect
rlm@0: programmatically.
rlm@0: 
rlm@0: 2.) Strip down open-al to a minimal version that only has my device
rlm@0: and deal with selecting the right open-al library at a higher level,
rlm@0: depending on whether the user wants to record sound or actually hear
rlm@0: it.  I don't like this because I can't easily benefit from
rlm@0: improvements in the main open-al distribution. It also would involve
rlm@0: more significant modification to jMonkeyEngine3's logic which selects
rlm@0: the appropriate C-artifact at runtime.
rlm@0: 
rlm@0: 3.) Get this new device added to open-al, and provide a java wrapper
rlm@0: for it in a separate artifact. Problem here is that this device does
rlm@0: not have the same semantics as the other devices --- it must be told
rlm@0: to render sound, doesn't support multiple user-created contexts, and
rlm@0: it exposes extra functions for retrieving the rendered sounds. It also
rlm@0: might be too "niche" for open-al proper.
rlm@0: 
rlm@0: 4.) Maybe abandon the device metaphor and use something better suited
rlm@0: to my problem that /can/ be done as in (1)?
rlm@0: 
rlm@0: 
rlm@0: I'm sure someone here knows enough about open-al's devices to give me
rlm@0: a better solution than these 4!  All help would be most appreciated.
rlm@0: 
rlm@0: sincerely,
rlm@0: --Robert McIntyre
rlm@0: 
rlm@0: