Re: Question about distributing modifications to open-al

Those links should be
http://aurellem.com/audio-send/html/send.html

for the code and

http://aurellem.com/audio-send/html/add-new-device.html

for the steps to add a new device.

sorry about that,
--Robert McIntyre


On Thu, Oct 20, 2011 at 8:56 AM, Robert McIntyre <[email protected]> wrote:

> 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