Replacement for OpenAL

[Tex Killer]

Look at what is on YSE's fork:
https://github.com/yvanvds/yse-soundengine/commit/84aebf06dfab94b31d2523d2a0563e9ba3a673b7

There seems to be an implementation with DirectSound there on the file yse/io/native/windowsWASAPI.cpp, so I think that maybe all that would need to be done to add support the other platforms would be to implement the other files on that "native" folder following the same interface

[FRex]

Apparently it used to use port audio (which has liberal license) and then switched to juce?
The project also migrated to github in the meantime it seems.
https://code.google.com/p/yse-soundengine/

Also there is the question of what is the point of SFML audio if this gets in it. What is the point of wrapping a C++, simple to use, rich API in almost identical one? Wrapping OpenAL makes a lot of sense because of the scarrrry C interface that Loki made to reassemble the scarrrry OpenGL C interface (which we also wrap) but this one - I don't see the point. So far SFML is just wrapper/glue code that ties together a lot of C/ObjC OS APIs and few cross platform but very spartan APIs like GL, AL, FT, stbi etc. because it makes (a lot of) sense to make them easier to use, especially the OS windowing/input/context ones which get crazy specific and require a lot of code per platform. AL has only sound output and libsnd is only loading of the sound files so it makes sense these two are tied together by SFML but just dumping one library - a ready, fully featured C++ engine that does everything - into SFML and wrapping it up in a 1:1 wrapper makes no sense to me. It's like wrapping SDL or GLFW in SFML Window and Graphics (which we don't do).


As for 3D audio, I don't know how Irrklang does it exactly (do all OS APIs have 3D?) but it goes down to platform API(ALSA, CoreAudio, etc.) on each platform and wraps them in its' own cross platform API. It's closed source but free for non commercial use.

[Tex Killer]

Apparently it used to use port audio (which has liberal license) and then switched to juce?
The project also migrated to github in the meantime it seems.
https://code.google.com/p/yse-soundengine/

Didn't know that 
So the github project probably has kept this license without considering JUCE's GPL license.

Also there is the question of what is the point of SFML audio if this gets in it. What is the point of wrapping a C++, simple to use, rich API in almost identical one? Wrapping OpenAL makes a lot of sense because of the scarrrry C interface that Loki made to reassemble the scarrrry OpenGL C interface (which we also wrap) but this one - I don't see the point. So far SFML is just wrapper/glue code that ties together a lot of C/ObjC OS APIs and few cross platform but very spartan APIs like GL, AL, FT, stbi etc. because it makes (a lot of) sense to make them easier to use, especially the OS windowing/input/context ones which get crazy specific and require a lot of code per platform. AL has only sound output and libsnd is only loading of the sound files so it makes sense these two are tied together by SFML but just dumping one library - a ready, fully featured C++ engine that does everything - into SFML and wrapping it up in a 1:1 wrapper makes no sense to me. It's like wrapping SDL or GLFW in SFML Window and Graphics (which we don't do).

Well, so if someone else has already done what needs doing outside SFML, the best to do would be to dump the Audio module altogether from SFML and proccess audio independently? What about the SFML user's codes that uses the SFML Audio module? Or should SFML keep using another library with its drawbacks (in this case the LGPL license)? I don't think that is a valid argument, but I also don't know if YSE is in a state that can be used to replace OpenAL on SFML. We shall see, I guess.

As for 3D audio, I don't know how Irrklang does it exactly (do all OS APIs have 3D?) but it goes down to platform API(ALSA, CoreAudio, etc.) on each platform and wraps them in its' own cross platform API. It's closed source but free for non commercial use.

I don't think all OS APIs have 3D functions. I believe that spatialization is done by the libraries (OpenAL, FMOD, and you said irrKlang) by software, and the platform only gets the output samples, but I am no expert. All I know is that spatialization can be done by software, and that it isn't that resource hungry (at least without high order effects like reflections and such).

[Laurent]

May I ask what "problem" you guys are trying to solve? OpenAL is native on OS X and iOS, and the only drawback of OpenAL-Soft and its LGPL license is that you can't link it statically, which is a concern only on Windows. But then what's the problem of having this DLL? A program is made of several files (resources, external libs, config, ...) what's so bad with this extra DLL file?

SFML is very unlikely to switch to another audio back-end. If you want to do something useful, you can create your own implementation of OpenAL (*) with a more permissive license.

(*) OpenAL, like OpenGL, is only a specification. It's OpenAL-Soft, its only viable implementation, that we use on Windows and which is LGPL.

[eXpl0it3r]

I'm not really trying to solve anything, I'm discussing more theoretical. IF there's a more permissive lib out there that does what OpenAL does, I'm really interested in hearing. However I doubt there's anything, thus the "theoretical".

[Laurent]

OpenAL is really the best back-end for SFML, since it's just an abstraction over the various system-specific libraries for audio recording and playback (it also adds spatialization, but this one is more a bonus than a requirement). And since it's an open specification, we are not tied to a specific library -- we use at least two different implementations of it in SFML. I really doubt there is something similar that we could use instead, and why would we do that anyway?

[eXpl0it3r]

Well if one doesn't know the available options, one can't really judge. I don't think there's anything better, but I've been wrong before.

[Tex Killer]

May I ask what "problem" you guys are trying to solve? OpenAL is native on OS X and iOS, and the only drawback of OpenAL-Soft and its LGPL license is that you can't link it statically, which is a concern only on Windows. But then what's the problem of having this DLL? A program is made of several files (resources, external libs, config, ...) what's so bad with this extra DLL file?

My main concern is that LGPL explicitly allows for the user of my software to replace OpenAL with a modified version (in this case, a modified .dll), and with that he could maybe leak my game's sound resources. Another thing that would be nice to have is the music synthesis that YSE provides, and last but not least, having a way of porting the audio code over to any platform whatsoever by simply porting the low level hardware functions (audio devices control and samples input/output).
Of course, OpenAL is supported almost anywhere, but maybe someone would want to port his SFML code to an embedded device or something that does not have an OpenAL implementation (who knows?). Having completely platform-independent code for most functionality can't be bad.

SFML is very unlikely to switch to another audio back-end. If you want to do something useful, you can create your own implementation of OpenAL (*) with a more permissive license.

(*) OpenAL, like OpenGL, is only a specification. It's OpenAL-Soft, its only viable implementation, that we use on Windows and which is LGPL.

I don't know the OpenAL API in detail, but I imagine it is as big and as hard to deal with as the OpenGL API, so that would be a pain in the ass. Idealy, I believe that SFML could deal with the audio (and video) back-ends through interfaces, being able to use OpenAL or anything else by the user's choice.

[...] I guess I'll create a ticket on the YSE project to clarify things.

The YSE developer has anwered our questions: https://github.com/yvanvds/yse-soundengine/issues/1
It seems that even JUCE's developer doesn't know the GPL license he is using and is giving out bad advice, but YSE's developer has said it was possible to strip JUCE's code, as long as we manage to replace it with an IO library that supports all of the platforms used (and port some code to standard C++).

[FRex]

My main concern is that LGPL explicit allows for the user of my software to replace OpenAL with a modified version (in this case, a modified .dll), and with that he could maybe leak my game's sound resources.

You can't prevent that other than by quitting programming. They have your stuff on their machine. There are tools to peek at programs and data in RAM, there is no way around it.

[Tex Killer]

My main concern is that LGPL explicit allows for the user of my software to replace OpenAL with a modified version (in this case, a modified .dll), and with that he could maybe leak my game's sound resources.

You can't prevent that other than by quitting programming. They have your stuff on their machine. There are tools to peek at programs and data in RAM, there is no way around it.

There are ways of making it hard, and I've also listed some other reasons for having platform-independent code for audio and the music synthesis. Also, YSE supports MIDI reproduction.

[Jesper Juhl]

There are ways of making it hard

Sure. But usually, once you attach a debugger it's not that hard. In any case, why bother? Whatever you do, it's going to get ripped/pirated anyway, is your time really well spent trying to prevent that (which you can't anyway).

[eXpl0it3r]

MIDI and synthesizer support are a wohle different thing and jusy because it can be done, doesn't mean it would get added. SFML's goal is to provide a higher level API for lower level stuff, and providing a few convenience classes.
Synthesizers can be built on top of SFML and are arguably in the scope of SFML.
MIDI support is also questionable as past discussions have shown.

Your platform code argument is still something I don't fully get...
DirectSound or PulseAudio are still just libraries/API. Where these APIs get called by OpenAL or SFML doesn't really help much, in the end someone has to write the implementation for that platform. If the maintainers of OpenAL can focus on that, while ee can deal with other stuff, it's alot better. If OpenAL isn't supported on a platform it's still possible to implement it for that platform and SFML doesn't need to change anything...

[Tex Killer]

There are ways of making it hard

Sure. But usually, once you attach a debugger it's not that hard. In any case, why bother? Whatever you do, it's going to get ripped/pirated anyway, is your time really well spent trying to prevent that (which you can't anyway).

I am not even talking about piracy, but as far as I know it is not that easy to extract game resources from RAM (even with debugger, as long as the binary has no symbols in it). If procedural music is used it would be even harder to do that, since audio would not come from a fixed resource file, and it might also be hard to detect and extract separated sounds when multiple sounds are being played (music background, sound effects, etc). "Wasted time" is also not a good reason to reject an improvement, since I am willing to use my time for the porting required. Seems like you guys just hate any closed-source (or closed-resource, don't know if that is a thing) iniciatives.

But that is only MY main reason for looking at OpenAL replacements right now, there are other reasons that you guys are just ignoring.

Your platform code argument is still something I don't fully get...
DirectSound or PulseAudio are still just libraries/API. Where these APIs get called by OpenAL or SFML doesn't really help much, in the end someone has to write the implementation for that platform. If the maintainers of OpenAL can focus on that, while ee can deal with other stuff, it's alot better. If OpenAL isn't supported on a platform it's still possible to implement it for that platform and SFML doesn't need to change anything...

I believe that porting OpenAL is a hell of a lot harder than just porting some low level platform functions related to audio input/output, but again, I am no expert. My suggestion wouldn't be to drop OpenAL altogether, but at least to use it through abstract interfaces that could be implemented with other back-ends (maybe even change back-ends at compilation-time via defined constants). As I've already explained, it would be good to have completely platform-independent code taking care of all audio processing and porting the audio to any platform by just porting the low level audio input/output functions.

If you guys are really that averse to allowing multiple audio back-ends I might consider implementing those interfaces on my own code, but I would rather not.

P.S.: This forum has 11111 Posts

[Hapax]

This forum has 11111 Posts

Thirty-one?
Oops. Made another post 

[Laurent]

I don't know the OpenAL API in detail, but I imagine it is as big and as hard to deal with as the OpenGL API,

Not at all. Audio is easy, and doesn't evolve like graphics. So the OpenAL API is relatively straight-forward. The SFML API is a close abstraction of it.

But that is only MY main reason for looking at OpenAL replacements right now, there are other reasons that you guys are just ignoring.

What are your other reasons? I couldn't find them (but it's probably me -- sorry).

If you guys are really that averse to allowing multiple audio back-ends I might consider implementing those interfaces on my own code, but I would rather not.

We are not against anything, it's just that right now I (and probably others) don't see the benefit of starting this huge work. We rely on a well established and implemented audio API, similar to the one we use for graphics. So far that's perfect for SFML.

If the problem is the DLL... (and I can't imagine anything else) look at all the programs installed on your computer. They all use tons of DLLs. Even the operating system is made of tons of shared libraries. Even if we implement something lower-level, it will still rely on DirectSound, ALSA, or whatever libraries that use DLLs. Does anyone care about it?

I'd really like to understand your motivation.