Migration to JUCE in a 3D audio engine

Hello, a bunch of questions here.

Background:

I've been working on an advanced 3D sound engine since last year. (Advanced here means users have full control of all sound buffers, lots of classes are available for audio buffer manipulation, and i like to implement composing tools later on). I went for portability and used libsndfile, PortAudio and a lot of Boost internally. At the moment the library works on windows, mac and linux.

But now that i try to port it to Android it turns out that not everything was a portable as I thought it would be. Mainly libsndfile is giving me trouble, but in general setting up a toolchain to build all dependencies for Android turns out te be quite daunting. And then I discovered JUCE! So I wonder if switching to JUCE might be a lot easier to maintain and have others compile the thing as well (it is an open source project).

Questions:

  • license: I use the Eclipse public license at the moment. The engine is open source, but commercial projects should also be able to use it. Is this still possible if I use JUCE in the library? (I'm not talking about the core, but the audio classes.)
  • pointer containers: I can use OwnedArray instead of boost::ptr_vector and boost::ptr_list, but is there a class that can replace boost::ptr_map? (I can work without, but it would be handy.)
  • loading files in memory: I see AudioSource normally uses a callback to read the next block of data. Can I abuse that to load the entire file to an internal buffer or is there another class to do so? (I haven't discovered one yet, and loading buffer by buffer is not efficient for multiple sources playing the same file.)
  • IO callbacks: One thing i didn't find are callbacks for file IO. Libsndfile had some function pointers available for tell, read, seek, write and length with which i could pass handlers for custom filesystems. This is important because most game engines work with data packs instead of separate sound files. Am I overlooking those or do they simply not exist?
  • audio devices: It looks like i need to create all available audio devices to access most information about them (like available channels, latency...) I would like to give the engine users that information. It is ok to create all available device on startup, or would you advice against that?

That's it for now. Thanks for your time and JUCE in general.

Regards,

yvan

 

Edit: corrected spelling of JUCE :-S

then I discovered JUSE! So I wonder if switching to JUSE

JUCE (Jules' Utility Class Extensions)

I'm impressed by your ability to repeatedly spell it wrong when the webpage you're looking at has it in massive letters at the top, as well as using the word absolutely everywhere, in the URL, the browser title, etc!

Re: license, it's GPL - there's nothing stopping you mixing it with other more permissive open-source licenses AFAIK.

I don't know what boost::ptr_map does, but generally I use std::map nowadays. I've considered adding a juce map class, but it seems a bit superfluous when the std one is already very good.

Obviously you can load files into memory, just stick it into an AudioSampleBuffer, there are many ways of doing that.. And only ancient C programmers use file callbacks these days - in juce you'd create a subclass of InputStream (although there may already be a subclass that does what you need).

Opening all the audio devices at startup would be a bad move. Depending on the platform and driver, there are situations where some drivers will get screwed up by this, and it could be slow. Better to use AudioDeviceManager to provide the user with settings.

I'm so embarrased. I can't believe I had the wrong library name in my head for days. That's a bad first impression I'll have to compensate for.

Anyway, thanks for your answers. I think they'll get me started.

I tried to avoid std::map because the insert function copies objects when you add them to the container. Emplace would be the better choice, but the microsoft implementation actually still uses the copy constructor. (Although it might have changed in VC++2013 because now there's also support for variadic templates. I'll have to check that out.)

Regards,

yvan