Replacement for OpenAL

[Tex Killer]

Yeah, I've searched for a while, but I am surprised I didn't find any cross-platform library to compute spatial audio. It shouldn't be so hard, right? The actual audio output could be provided by multiple libraries, but spatial audio calculations seems to be exclusive to OpenAL and FMOD (proprietary).

There are some obscure libraries able to compute HRTF audio (which uses a "model" of the ear to make realistic sounds for each channel, at least on headphones), but I also couldn't find a cross-platform library for that. The closest I got was the slab3d library (http://slab3d.sonisphere.com/), that is licensed on the NASA Open Source Agreement, but it is said on the site that it is made for Windows, so I am not sure if it would work on other platforms. It also has a lot of features that are not neccessary for SFML.
There is a demo that someone made using it here (watch it with headphones):


By the way, if I understood the NASA license correctly, we could use the library (even with static linking) as long as the library's code and eventual modifications we do are released, and we can keep our own code closed. Would that license be acceptable to use on SFML?

[zsbzsb]

Huh? What does this have to do with SFML? What would it be used for? Why in the world should it be part of the core of SFML?

[Tex Killer]

Huh? What does this have to do with SFML? What would it be used for? Why in the world should it be part of the core of SFML?

It does sound spatialization, and I believe that sound spatialization is the main feature that is tying SFML to OpenAL. I am not saying that it should be a part of SFML, my question was only about the NASA license.

[eXpl0it3r]

System Requirements slab3d runs under Windows 2000 and higher. For low-latency audio output, slab3d supports ASIO and DirectSound sound device drivers. See your sound device documentation for information on obtaining and installing these drivers. slab3d is developed using the ASIO SDK and the DirectSound SDK. To obtain the ASIO SDK, see www.steinberg.net under Support | 3rd Party Developers. For DirectX information, see www.microsoft.com/directx and msdn.microsoft.com/directx. If executing a slab3d application reports a missing DLL, you most likely require a more thorough version of the "DirectX End-User Runtime" (see the Microsoft Download Center at www.microsoft.com/downloads). The XScape application requires the "Microsoft XNA Framework Redistributable 4.0".

It's Windows only (DirectSound), thus doesn't fit the requirements. Besides OpenAL is the "standard". It's used in thousands of applications and supported on all kinds of platforms, thus it's guaranteed to run stable nearly everywhere.

[Tex Killer]

System Requirements slab3d runs under Windows 2000 and higher. For low-latency audio output, slab3d supports ASIO and DirectSound sound device drivers. See your sound device documentation for information on obtaining and installing these drivers. slab3d is developed using the ASIO SDK and the DirectSound SDK. To obtain the ASIO SDK, see www.steinberg.net under Support | 3rd Party Developers. For DirectX information, see www.microsoft.com/directx and msdn.microsoft.com/directx. If executing a slab3d application reports a missing DLL, you most likely require a more thorough version of the "DirectX End-User Runtime" (see the Microsoft Download Center at www.microsoft.com/downloads). The XScape application requires the "Microsoft XNA Framework Redistributable 4.0".

It's Windows only (DirectSound), thus doesn't fit the requirements. Besides OpenAL is the "standard". It's used in thousands of applications and supported on all kinds of platforms, thus it's guaranteed to run stable nearly everywhere.

I know that, but I am considering the alternatives (also there might be a platform that doesn't support it, who knows). Anyway, I believe that the ideal would be to have all the general processing done on platform-less code (with optional hardware acceleration on supported platforms), and depend on the platform only for the most low level features: in this case, I believe it would be to control audio input/output devices and to input/output samples from/to them. Any platform must have a way to provide that if it has sound, so a simple porting would always be possible.

About the DirectSound issue, slab3d also supports memory buffer input/output. I believe it should be possible to strip all platform code from it and keep it working, but it seems a bit overcomplicated for SFML anyway. What I am curious about is the NASA license, that I've never seen before. Does any of you know how it works and if I understood it right?

[Tex Killer]

Yeah, it seems nobody knows that NASA license, but it is ok.

After about 2 days of searching for audio libraries, I've found this one, that works on Window, Linux, MacOS, Android and iOS: http://attr-x.net/yse/

I've tested the demo and it looks good. From what I could see it does everything SFML needs (and even a bit more, like MIDI reproduction and music synthesis, that might be good additions to the current functionality), and it is licensed with the Eclipse Public License, which is more permissive than OpenAL's LGPL one (and doesn't restrict static linking, even for commercial applications): http://www.eclipse.org/legal/epl-v10.html

What do you guys think?

[eXpl0it3r]

Might have wanted to dig a bit deeper here.

YSE is basically just a synth and midi player with an audio play API built over JUCE. And you really don't want to look at their licensing...

[Tex Killer]

Might have wanted to dig a bit deeper here.

YSE is basically just a synth and midi player with an audio play API built over JUCE. And you really don't want to look at their licensing...

I have seen JUCE's license, but I assumed YSE no longer uses it, or at least YSE's license does not deppend on JUCE's license. How can YSE's license be more permissive than JUCE's license if it uses/includes JUCE?

[binary1248]

SFML also makes use of OpenAL and libsndfile although they both lie under LGPL whereas SFML lies under zlib. As long as the licenses permit using them in those certain ways, nothing prohibits you from doing it. What you can't do is treat those libraries as if they lie under the same license as the library that makes use of them. In the end, your project will directly and indirectly make use of many libraries, all with their own licenses, and you will have to make sure you are using all of them in the ways they allow you to use them.

[eXpl0it3r]

As binary1248 said, the Eclipse license only covers the source code of the YSE library itself and doesn't expand to its dependencies, e.g. you could link YSE statically, but you'd still need to pay for a commercial JUCE license if you'd want to sell your game.

I've split this topic from the other thread, since it started to go way off topic.

[Tex Killer]

As binary1248 said, the Eclipse license only covers the source code of the YSE library itself and doesn't expand to its dependencies, e.g. you could link YSE statically, but you'd still need to pay for a commercial JUCE license if you'd want to sell your game.

I've split this topic from the other thread, since it started to go way off topic.

I've answered binary1248 post on that topic without knowing of the change, but I'm reposting it here:

SFML also makes use of OpenAL and libsndfile although they both lie under LGPL whereas SFML lies under zlib. As long as the licenses permit using them in those certain ways, nothing prohibits you from doing it. What you can't do is treat those libraries as if they lie under the same license as the library that makes use of them. In the end, your project will directly and indirectly make use of many libraries, all with their own licenses, and you will have to make sure you are using all of them in the ways they allow you to use them.

OK, then. So, the YSE site and documentation are wrong for not informing the user that he must adhere to JUCE's license to use YSE? Because on the download section you can get the YSE .dll (for windows, at least), and there is no mention of JUCE's license anywhere on that site.

Also, take a look at their Wiki here: https://github.com/yvanvds/yse-soundengine/wiki
"The library uses the JUCE toolkit for audio input and output, but you don't need JUCE once your library is in place."
That means we can implement input and output without JUCE and still use YSE, right?

I suppose all audio processing is done with Pure Data, a BSD licensed program that provides a library version, so I guess that license shouldn't be a problem as long as JUCE is out of picture.

[eXpl0it3r]

My guess is, that the author doesn't properly know, how the licensing works and as such he statement on the wiki is likely wrong.

Going further, I think he can't even use the Eclipse license on his code, since JUCE is being used and JUCE falls under GPL (or commercial license) and as we all know, GPL is an infectious license. If you use a GPL library (not LGPL), your code has to be GPL as well.

[Tex Killer]

My guess is, that the author doesn't properly know, how the licensing works and as such he statement on the wiki might be wrong.

Going further, I think he can't even use the Eclipse license on his code, since JUCE is being used and JUCE falls under GPL (or commercial license) and as we all know, GPL is an infectious license. If you use a GPL library (not LGPL), your code has to be GPL as well.

That was my first reasoning for ignoring the JUCE's license. Anyway, the Eclipse license allows for modifications of the library, right? If YSE really uses PD for most (or all) of the sound computations and someone makes a modified version removing all JUCE code from it, wouldn't that be usable?

[eXpl0it3r]

I don't know, since I'm not a lawyer.

I've no idea, if it would be allowed to claim that this software is developed for the commercial licenses of JUCE and then one wouldn't fall under GPL (ofc it should be mentioned somewhere). If this is allowed, then there's no licensing issue, just missing information.

If it's not allowed, then the question is: Under what does the code now fall. As per JUCE's GPL, it would need to be GPL, so if I were to use YSE right now, under which license would it fall? If it's GPL, then we wouldn't be allowed to strip the JUCE code.

Maybe I got this all of this backwards anyways... I guess I'll create a ticket on the YSE project to clarify things.

[Tex Killer]

I don't know, since I'm not a lawyer.

I've no idea, if it would be allowed to claim that this software is developed for the commercial licenses of JUCE and then one wouldn't fall under GPL (ofc it should be mentioned somewhere). If this is allowed, then there's no licensing issue, just missing information.

If it's not allowed, then the question is: Under what does the code now fall. As per JUCE's GPL, it would need to be GPL, so if I were to use YSE right now, under which license would it fall? If it's GPL, then we wouldn't be allowed to strip the JUCE code.

Maybe I got this all of this backwards anyways... I guess I'll create a ticket on the YSE project to clarify things.

That would be nice 
It would also be nice to know which PD extras (or externals, don't know the right name) YSE uses, since some of them are under GPL as well. If it is just the core libPD it should be under the BSD license.

If this can be done with just low level porting of audio input/output, I am willing to work on that porting 

Edit: Saw your issue there, it seems nice. I've also sent an e-mail to the developer, lets now wait for an answer.

By the way, I didn't even remember I had an account on Github... lol