Messages

31

General discussions / Re: Replacement for OpenAL

« on: September 21, 2014, 12:25:10 am »

Just because I've mentioned leaking assets, everyone is talking about that. Since the begginning I've said that that was only my main concern, but that there are other uses to exchangeable back-ends and platform-independent audio computation being separated from low level IO.

I've seen tools that employ highly sophisticated pattern recognition and data mining algorithms along with rudimentary AI to extract all kinds of data out of a frozen process. People can get hold of them fairly easily if they know what to look for.

You would still only get the buffer that is loaded (ex: one second of sound). To get the entire resource you would have to do that at every buffer refill (ex: every second), and join them together on the hard drive. That might even not be possible if the sound is being generated proceduraly, but I don't know that for sure.

Anyway, the most interesting approach I am studying now isn't even changing SFML Audio at all, but the possibility of an OpenAL API wrapper of YSE, or something like that, while keeping its Eclipse license.

32

SFML projects / Re: Tiny Bomber - a game for Ludum Dare #23

« on: September 20, 2014, 11:17:14 pm »

Seems so awesome from the videos! Congratulations!

Did you program the physics simulations manualy? I assume you use particles for both sand and water, right?

33

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 11:00:35 pm »

So, are you saying that it would be possible (and even easy) to implement the OpenAL API using YSE, for example? How many and which functions have to be implemented for an OpenAL API compatible library? (Or at least for one compatible with SFML's use of the OpenAL API)

Not to be rude or anything, but you could have easily looked up a tutorial or two on OpenAL yourself to get at least a vague idea how easy or hard this is before suggesting SFML totally reimplement its audio module.  Most of us probably know nothing about YSE so you'd likely get an answer more quickly by researching yourself.

For instance, here's the spec: http://openal.org/documentation/openal-1.1-specification.pdf  It's "only" 60 pages, and I found it pretty readable back when I was curious about OpenAL.

I had seen that specification, but it is meant for users, and not developers.
I've also found this PDF: http://open-activewrl.sourceforge.net/data/OpenAL_PGuide.pdf
It has a list of functions in a very organized way, but it seems to be for the old Creative OpenAL, not for OpenAL Soft. Can you guys take a look and confirm that those are all the functions that SFML uses from OpenAL?

About the DLL stuff, I've discussed that on the previous posts. My main motivation would be to prevent the leaking of audio resources.

If I remember your previous posts correctly, it sounds like your threat model is a user who is:

• sophisticated enough to swap out an OpenAL .dll for an alternative implementation of the library that somehow gives him direct access to the sound assets
• but NOT sophisticated enough to somehow locate the sound data in RAM and copy them somewhere else

Does such a user really exist?

At any point, someone might fork OpenAL Soft (for example) and make a version of the DLL capable of saving sound files as sounds are played (even the separate resources on separate files, as OpenAL is the one that joins them so it has access to the separate sources). Such a DLL could then be shared on the internet to anyone anywhere, and any game/app with the OpenAL DLL would be completely open for audio resources extraction by anyone (even someone that knows nothing of any programming language).

And assuming they were seriously going to try this sort of attack, couldn't they just as easily go after the even lower-level shared library that they know almost every program on their machine has to use for audio? (ie, the audio drivers?)

It's not clear to me that there's any real benefit to protecting against this.

I don't think so. You can take the game/app output samples and save them on a sound file, but not the resources, since they would be mixed by the static library software in real time. There is still the possibility of hacking the RAM to try and get the resources, but that is way more complicated than just replacing a DLL, specially if sounds are played in small buffers instead of completely in memory.

Incidentally, I'm pretty sure dynamic linking is not the only way to satisfy the LGPL license.  It just seems to be by far the simplest, most flexible and most composable method of satisfying it, last time I looked into this stuff.  IANAL, but I believe it would be legal to simply make the complete source code of your product freely available online, but none of the assets that go with it (iirc, the LGPL doesn't care about the input or output of the program; gcc has a vaguely similar exception which is why programs compiled with it don't get "infected" by the license).  Not quite sure if that helps with your situation, but if it does it might be easier than reimplementing sfml-audio from scratch with a new backend.

What about commercial products? Not everyone (or rather, almost nobody) is confortable sharing their commercial code as open source.

34

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 09:45:18 pm »

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.

So, are you saying that it would be possible (and even easy) to implement the OpenAL API using YSE, for example? How many and which functions have to be implemented for an OpenAL API compatible library? (Or at least for one compatible with SFML's use of the OpenAL API)

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).

The first would be the possibility of easily porting audio to any platform, even if they don't support OpenAL, by porting only the few low level IO functions. Aside from that, there is maybe the possibility of easily integrating music synthesis and MIDI reproduction on SFML.

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.

About the DLL stuff, I've discussed that on the previous posts. My main motivation would be to prevent the leaking of audio resources.

35

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 07:24:59 pm »

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

36

SFML projects / Re: Rage - a "modern" rogue-like

« on: September 20, 2014, 07:02:00 pm »

Interesting!

Are you planning on releasing it? What about other platforms?

Anyway, congratulations on the project, seems nice so far.

37

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 06:23:03 pm »

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.

38

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 06:12:48 pm »

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++).

39

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 05:28:30 am »

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).

40

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 04:20:00 am »

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

41

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 02:52:53 am »

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

42

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 02:29:21 am »

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?

43

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 02:16:43 am »

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.

44

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 01:30:57 am »

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?

45

General discussions / Re: Replacement for OpenAL

« on: September 20, 2014, 12:14:23 am »

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?