Replacement for OpenAL

[Tex Killer]

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.

[Ixrec]

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)

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.

Not to be rude or anything, but the way you've written your posts so far, it kinda sounds like you're asking us to do all the research when it comes to how easy or hard reimplementing OpenAL with YSE or whatever would actually be.  If you're serious about this, you may want to google a tutorial or two on OpenAL yourself to get at least a vague idea about it before discussing or asking for help with total reimplementations of SFML's audio module or OpenAL itself.  Most of us probably know nothing about YSE so you'd likely get a few concrete answers more quickly by researching yourself.

For instance, here's the spec for OpenAL 1.1: 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.

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?

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.



Incidentally, I'm pretty sure dynamic linking is not the only way to satisfy the LGPL license, though it did seem 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 statically link OpenAL (which you'd have to figure out yourself), then 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.

[Tex Killer]

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.

[binary1248]

So... let me get this straight. You are suggesting SFML consider replacing OpenAL with YSE "just" so it grants developers supposedly better immunity from users extracting audio assets from their game?

I don't know where this is going, but such "issues" about DRM and IP protection have already been discussed in the past, all with more or less the same outcome: No matter how hard you try, they will still manage to do it. The discussions in the past however were different, because they didn't suggest SFML going out of its way to give developers the false hope that it would also try to hinder such users.

In the end, its not about how "easy" or "hard" something is to do. If it can be done, it will be done. And the worst part is: All it takes is one individual to leak your assets and even the lesser capable will be able to get hold of them. As such, claiming that static linking the whole executable so that the "DLL replacement trick" can't be performed just deters casual people, but determined and capable people will probably end up scanning the address space of the process for audio data and what not anyway. And you know what? 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 might have already thought of embedding your assets using some kind of encryption into your executable, however the same applies here.

In the end, if your game is meant to be played by more people then the number of developers, they will always have more manhours at hand to break apart what you have worked on. DRM and protection shouldn't cost you or anyone else more time than the eventually leaked assets are worth, and this is assuming that they would be leaked.

Really... all I can say is the same as has been said all those times in the past. Concentrate on getting your game/app working and popular and think of such things later. As demotivating as it might sound, not many people who have openly expressed their concerns about such issues actually end up anywhere near where it would have made any difference.

[Jesper Juhl]

Personally I don't see the point.
If someone really wants to rip off your sounds, they will. DLL or no DLL - doesn't really matter if it's dynamically or statically linked. In the end they can just record whatever comes out the speakers anyway.
From my perspective the major fail is assuming that someone would even want to in the first place. This sounds to me like the people who don't want to discuss their game ideas since "someone might steal them". Well, newsflash, in general; no-one can be bothered to. Whatever you've come up with (sound or idear wise) is really not that special and noone really cares (and those who do won't be stoppede by a DLL not being easily swapable).  Just my perspective.

[Tex Killer]

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.

[binary1248]

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

Well... without this main concern, there wouldn't be any compelling reason to consider changing the way things work, so it should naturally be the first thing that gets discussed.

there are other uses to exchangeable back-ends and platform-independent audio computation being separated from low level IO.

OpenAL is, just like SFML, a library that sits on top of the raw OS APIs. If SFML wanted to go lower, it would end up writing a sound implementation for every platform that is to be supported, and considering OpenAL does exactly that and much more, why bother going lower?

Sure there are other backends such as YSE and all those other proprietary libraries. Since SFML is open source and can't force its users to make use of proprietary libraries, they are already out of the question. This leaves the open source ones up for discussion. Considering OpenAL and YSE both satisfy SFML's requirements from what I can tell, a decision has to be made which of them to use. Supporting multiple backends "just because we can" hasn't caught much traction, neither regarding audio, networking, or the infamous OpenGL vs Direct3D debate. There have to be substantial benefits that warrant the effort that has to be invested in rewriting the module in question to use a new backend, or even worse to abstract all backends so they can be interchanged at the developer's will.

At the end of the day, it all boils down to: If it works, there is no need to fix it. People who want to be able to pick from multiple backends (OpenGL vs Direct3D or in our case OpenAL vs YSE) for philosophical reasons often don't bother mentioning their real intentions from the beginning, often leading to very convoluted debates that are fuelled purely by constructed arguments that have nothing to do with reality. SFML guarantees that its behaviour stays consistent no matter what backend is in use, so being able to exchange them when multiple are available makes no sense if you restrict yourself to the SFML API.

Feature requests on their own are one thing, adding features to the library solely to justify adding/exchanging a backend is another. They should be discussed separately. If it turns out that realizing a certain feature with the currently used libraries is not possible, then and only then can an alternative even be considered. As it stands, the audio functionality that SFML exposes can be fully realized by OpenAL, on all platforms, so providing multiple backends is just wasted effort if you ask me.

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.

So... where would the data come from? Surely the audio data (encrypted and what not) that is embedded into the executable is somewhere, right? It's even easier to track down where that data is located if the decryption/decoding is done on a periodic basis in order to load a small number of samples at a time. This is probably even easier to do using static analysis of the executable if indeed everything was statically linked.

That might even not be possible if the sound is being generated proceduraly, but I don't know that for sure.

Even easier for them to extract the generator code then, right?

That dynamic analysis case that I mentioned was just an example. I just wanted to point out that there are ways, many of which I probably have no idea, in which experienced people can eventually extract the data. In the end you are just shooting yourself in the foot by attempting to make it harder for them to achieve what they want to do. More code means more possibilities for bugs to creeps in, larger executable size, higher maintenance cost (think of the tools you need to produce the full executable) and many other things. Is it really worth that much to you? Big companies have "problems" with piracy and people leaking assets as well, and although they might have hundreds of employees, and maybe even specialists that only deal with such issues, they don't bother jumping through nearly as many hoops as you are trying to.

You simply have to ask yourself: Is it really worth it? Even more so than those big companies that spend millions on content creation? If the answer is yes, please explain to us why. I am sure nobody here can understand as well as you do.

[Tex Killer]

If SFML wanted to go lower, it would end up writing a sound implementation for every platform that is to be supported, and considering OpenAL does exactly that and much more, why bother going lower?

I have already listed my reasons (LGPL-less, ease of porting for platforms without OpenAL and, for YSE at least, music synthesis and MIDI reproduction). Those might not be enough to justify changing SFML Audio code, but I would definitely work on that OpenAL API wrapper of YSE to keep my SFML code as it is, if the only functions to be implemented are those from this PDF: http://open-activewrl.sourceforge.net/data/OpenAL_PGuide.pdf

Supporting multiple backends "just because we can" hasn't caught much traction, neither regarding audio, networking, or the infamous OpenGL vs Direct3D debate. There have to be substantial benefits that warrant the effort that has to be invested in rewriting the module in question to use a new backend, or even worse to abstract all backends so they can be interchanged at the developer's will.

Well, you have mentioned OpenGL, and there we have a very strong reason to support multiple back-ends: Xbox doesn't support OpenGL. I believe that to be reason enough to try and abstract between OpenGL and DirectX, but lets leave that discussion where it already is: on the SFML 3 Vision thread.

You simply have to ask yourself: Is it really worth it? Even more so than those big companies that spend millions on content creation? If the answer is yes, please explain to us why. I am sure nobody here can understand as well as you do.

For me it is worth spending some time to get what I am after on the audio department, specially if I can integrate my modifications with SFML (like with the OpenAL API wrapper approach). Anyway, I guess I am just still surprised that there aren't any open source libraries that can really compete with OpenAL with a more permissive license. It is not that I am against open source projects (if I do the wrapper thing, it will be open source), but I don't like it when the open source libraries try to prevent "closed source" projects from using them. That is just my opinion, and I respect anyone that thinks otherwise.

Anyway, lets please stop talking about resource leaking and modifications to SFML for a while. I want to discuss the OpenAL API wrapper thing, specially its possibility of integration to SFML, and I am willing to code the wrapper even if nobody else is, as long as it isn't much trouble.

First, can someone (Laurent, eXpl0it3r, or someone else that knows SFML's use of OpenAL) confirm that the current OpenAL Soft API hasn't changed from the Creative OpenAL one on the following link, and that implementing those functions would be enough for SFML Audio to function?
http://open-activewrl.sourceforge.net/data/OpenAL_PGuide.pdf

[binary1248]

ease of porting for platforms without OpenAL

And these platforms are...? Directly from the YSE website:

It runs on Windows, Linux, MacOS, Android and iOS.

All these platforms are supported by OpenAL as well... So I don't understand what you mean when you say that more platforms can be supported by an additional YSE backend... In fact, I am fairly sure that you will not get better cross-platform portability from something other than OpenAL. Sure, some platforms won't support it, but often those platforms have their own proprietary APIs that are forced on everyone. I doubt there is a truly cross-platform audio library that supports platforms that OpenAL doesn't.

music synthesis and MIDI reproduction

But this is what I mentioned. Those features aren't part of the SFML feature set, so they can't be considered as a benefit over OpenAL if you are indeed limiting the usage of YSE to the SFML backend and not your own code as well.

Well, you have mentioned OpenGL, and there we have a very strong reason to support multiple back-ends: Xbox doesn't support OpenGL. I believe that to be reason enough to try and abstract between OpenGL and DirectX, but lets leave that discussion where it already is: on the SFML 3 Vision thread.

More like, Xbox still doesn't officially support OpenGL . At some point, when Microsoft notices that their stubbornness is hurting their sales figures, I'm sure they'll be a bit more... "open" to suggestions from the companies supplying the hardware inside the Xbox (who, surprise surprise, are part of Khronos). After all, it's not like the Xbox has specially designed hardware for it, Microsoft just decided not to allow installation of any ICDs on it which prevents the OpenGL API being exposed as well.

For me it is worth spending some time to get what I am after on the audio department

So... you aren't going through the same hassle for your graphics (if you have any that is)? "Protecting" graphics from being extracted is nigh impossible since the full dataset has to end up on the GPU at some point, so all I can say is save yourself the time if you are really trying to do that as well.

specially if I can integrate my modifications with SFML (like with the OpenAL API wrapper approach).

I still don't get what you are trying to do... If OpenAL and YSE are so similar in features, surely there is some sort of mapping between the OpenAL and YSE API that allows you to plug YSE in without having to write a compatibility wrapper around it just to make SFML happy.

Anyway, I guess I am just still surprised that there aren't any open source libraries that can really compete with OpenAL with a more permissive license. It is not that I am against open source projects (if I do the wrapper thing, it will be open source), but I don't like it when the open source libraries try to prevent "closed source" projects from using them. That is just my opinion, and I respect anyone that thinks otherwise.

See... the thing is... the larger the effort that is required to be put into a library, the more it is worth in non-monetary terms. People often don't like giving things away, as you already know. Providing a library for "free" is not equivalent to giving it away for free i.e. without any license restrictions. The license that is often chosen in such cases is a strong copyleft. Instead of requiring you to pay money for the right to do whatever you want with the library, you "pay" by sharing your code with the community in return (in the case of GPL), or in the case of LGPL, you "pay" by promising the developer that any modifications (for better or worse) made to the library are shared back as well, which requires that such modifications can even be made to begin with hence the linking restriction. People seem to forget that before money existed, it was normal for people to trade goods with one another. Obviously, if you had an issue with offering something that someone asked of you in return for something they have, you wouldn't end up trading with them, no matter how much you complain. The same applies to software as well. Closed source projects complaining about the "viral" nature of strong copyleft licenses are for lack of better words, greedy and selfish. They want to benefit from the library without providing anything of interest to the developers (not money obviously) in return. If they want to compensate in money, some projects might allow for dual-licensing, so that is also not an excuse. I really cannot sympathize with them in this regard.

Given what I have just said, you will find that any kind of highly complex library is often proprietary or strong copyleft. They aren't things that people can do in their spare time like SFML is, hence they want their time to end up being worth something more than their own personal enjoyment.

I want to discuss the OpenAL API wrapper thing, specially its possibility of integration to SFML, and I am willing to code the wrapper even if nobody else is, as long as it isn't much trouble.

Like I have said multiple times already, wrapping YSE in an OpenAL interface makes no sense if its API can be used directly in the SFML code anyway. Rather than writing the wrapper, you should probably focus on understanding how SFML's audio code works, so you can implement it using YSE if you so desire.

First, can someone (Laurent, eXpl0it3r, or someone else that knows SFML's use of OpenAL) confirm that the current OpenAL Soft API hasn't changed from the Creative OpenAL one on the following link, and that implementing those functions would be enough for SFML Audio to function?
http://open-activewrl.sourceforge.net/data/OpenAL_PGuide.pdf

Code: [Select]

$ grep "alCheck(" *.cpp
Listener.cpp:        alCheck(alListenerf(AL_GAIN, volume * 0.01f));
Listener.cpp:        alCheck(alListener3f(AL_POSITION, position.x, position.y, position.z));
Listener.cpp:        alCheck(alListenerfv(AL_ORIENTATION, orientation));
Listener.cpp:        alCheck(alListenerfv(AL_ORIENTATION, orientation));
Sound.cpp:    alCheck(alSourcePlay(m_source));
Sound.cpp:    alCheck(alSourcePause(m_source));
Sound.cpp:    alCheck(alSourceStop(m_source));
Sound.cpp:    alCheck(alSourcei(m_source, AL_BUFFER, m_buffer->m_buffer));
Sound.cpp:    alCheck(alSourcei(m_source, AL_LOOPING, loop));
Sound.cpp:    alCheck(alSourcef(m_source, AL_SEC_OFFSET, timeOffset.asSeconds()));
Sound.cpp:    alCheck(alGetSourcei(m_source, AL_LOOPING, &loop));
Sound.cpp:    alCheck(alGetSourcef(m_source, AL_SEC_OFFSET, &secs));
Sound.cpp:        alCheck(alSourcei(m_source, AL_BUFFER, 0));
SoundBuffer.cpp:    alCheck(alGenBuffers(1, &m_buffer));
SoundBuffer.cpp:    alCheck(alGenBuffers(1, &m_buffer));
SoundBuffer.cpp:        alCheck(alDeleteBuffers(1, &m_buffer));
SoundBuffer.cpp:    alCheck(alGetBufferi(m_buffer, AL_FREQUENCY, &sampleRate));
SoundBuffer.cpp:    alCheck(alGetBufferi(m_buffer, AL_CHANNELS, &channelCount));
SoundBuffer.cpp:    alCheck(alBufferData(m_buffer, format, &m_samples[0], size, sampleRate));
SoundSource.cpp:    alCheck(alGenSources(1, &m_source));
SoundSource.cpp:    alCheck(alSourcei(m_source, AL_BUFFER, 0));
SoundSource.cpp:    alCheck(alGenSources(1, &m_source));
SoundSource.cpp:    alCheck(alSourcei(m_source, AL_BUFFER, 0));
SoundSource.cpp:    alCheck(alSourcei(m_source, AL_BUFFER, 0));
SoundSource.cpp:    alCheck(alDeleteSources(1, &m_source));
SoundSource.cpp:    alCheck(alSourcef(m_source, AL_PITCH, pitch));
SoundSource.cpp:    alCheck(alSourcef(m_source, AL_GAIN, volume * 0.01f));
SoundSource.cpp:    alCheck(alSource3f(m_source, AL_POSITION, x, y, z));
SoundSource.cpp:    alCheck(alSourcei(m_source, AL_SOURCE_RELATIVE, relative));
SoundSource.cpp:    alCheck(alSourcef(m_source, AL_REFERENCE_DISTANCE, distance));
SoundSource.cpp:    alCheck(alSourcef(m_source, AL_ROLLOFF_FACTOR, attenuation));
SoundSource.cpp:    alCheck(alGetSourcef(m_source, AL_PITCH, &pitch));
SoundSource.cpp:    alCheck(alGetSourcef(m_source, AL_GAIN, &gain));
SoundSource.cpp:    alCheck(alGetSource3f(m_source, AL_POSITION, &position.x, &position.y, &position.z));
SoundSource.cpp:    alCheck(alGetSourcei(m_source, AL_SOURCE_RELATIVE, &relative));
SoundSource.cpp:    alCheck(alGetSourcef(m_source, AL_REFERENCE_DISTANCE, &distance));
SoundSource.cpp:    alCheck(alGetSourcef(m_source, AL_ROLLOFF_FACTOR, &attenuation));
SoundSource.cpp:    alCheck(alGetSourcei(m_source, AL_SOURCE_STATE, &status));
SoundStream.cpp:        alCheck(alSourcePlay(m_source));
SoundStream.cpp:    alCheck(alSourcePause(m_source));
SoundStream.cpp:        alCheck(alGetSourcef(m_source, AL_SEC_OFFSET, &secs));
SoundStream.cpp:        alCheck(alGenBuffers(BufferCount, m_buffers));
SoundStream.cpp:        alCheck(alSourcePlay(m_source));
SoundStream.cpp:            alCheck(alSourcePause(m_source));
SoundStream.cpp:                alCheck(alSourcePlay(m_source));
SoundStream.cpp:        alCheck(alGetSourcei(m_source, AL_BUFFERS_PROCESSED, &nbProcessed));
SoundStream.cpp:            alCheck(alSourceUnqueueBuffers(m_source, 1, &buffer));
SoundStream.cpp:                alCheck(alGetBufferi(buffer, AL_SIZE, &size));
SoundStream.cpp:                alCheck(alGetBufferi(buffer, AL_BITS, &bits));
SoundStream.cpp:    alCheck(alSourceStop(m_source));
SoundStream.cpp:    alCheck(alSourcei(m_source, AL_BUFFER, 0));
SoundStream.cpp:    alCheck(alDeleteBuffers(BufferCount, m_buffers));
SoundStream.cpp:        alCheck(alBufferData(buffer, m_format, data.samples, size, m_sampleRate));
SoundStream.cpp:        alCheck(alSourceQueueBuffers(m_source, 1, &buffer));
SoundStream.cpp:    alCheck(alGetSourcei(m_source, AL_BUFFERS_QUEUED, &nbQueued));
SoundStream.cpp:        alCheck(alSourceUnqueueBuffers(m_source, 1, &buffer));

[Tex Killer]

ease of porting for platforms without OpenAL

And these platforms are...? Directly from the YSE website:

It runs on Windows, Linux, MacOS, Android and iOS.

All these platforms are supported by OpenAL as well... So I don't understand what you mean when you say that more platforms can be supported by an additional YSE backend... In fact, I am fairly sure that you will not get better cross-platform portability from something other than OpenAL. Sure, some platforms won't support it, but often those platforms have their own proprietary APIs that are forced on everyone. I doubt there is a truly cross-platform audio library that supports platforms that OpenAL doesn't.

You didn't read my previous posts, or didn't understand them. YSE has all audio processing (spatialization and such) done by software, so the platform code is only related to input/output. That means it is much easier to port only that for a new platform that doesn't have an OpenAL port (lets say, for example, a new embeded hardware), than to port OpenAL.

music synthesis and MIDI reproduction

But this is what I mentioned. Those features aren't part of the SFML feature set, so they can't be considered as a benefit over OpenAL if you are indeed limiting the usage of YSE to the SFML backend and not your own code as well.

Of course I am considering my code, at least while SFML doesn't implement those features. The OpenAL API wrapper approach would be done to preserve the current SFML Audio code, it doesn't mean I won't use any other feature from YSE.

Well, you have mentioned OpenGL, and there we have a very strong reason to support multiple back-ends: Xbox doesn't support OpenGL. I believe that to be reason enough to try and abstract between OpenGL and DirectX, but lets leave that discussion where it already is: on the SFML 3 Vision thread.

More like, Xbox still doesn't officially support OpenGL . At some point, when Microsoft notices that their stubbornness is hurting their sales figures, I'm sure they'll be a bit more... "open" to suggestions from the companies supplying the hardware inside the Xbox (who, surprise surprise, are part of Khronos). After all, it's not like the Xbox has specially designed hardware for it, Microsoft just decided not to allow installation of any ICDs on it which prevents the OpenGL API being exposed as well.

They are already on their third platform. I don't think they plan on allowing OpenGL, specially because they own DirectX and DirectX is well known and used by many game companies. But again, lets leave this talk for the SFML 3 Vision thread.

For me it is worth spending some time to get what I am after on the audio department

So... you aren't going through the same hassle for your graphics (if you have any that is)? "Protecting" graphics from being extracted is nigh impossible since the full dataset has to end up on the GPU at some point, so all I can say is save yourself the time if you are really trying to do that as well.

I have no plans for that. Graphics code is a hell of a lot more complicated than audio code, and require more hardware acceleration as well, so it gets complicated. On the other hand, I wouldn't know how to extract textures from the video memory of an application, but we are talking about resource leaking again, lets stop.

specially if I can integrate my modifications with SFML (like with the OpenAL API wrapper approach).

I still don't get what you are trying to do... If OpenAL and YSE are so similar in features, surely there is some sort of mapping between the OpenAL and YSE API that allows you to plug YSE in without having to write a compatibility wrapper around it just to make SFML happy.

How would that work? OpenAL and YSE APIs are very much different, without a wrapper there is no way to just replace one by the other without changing the user's code (in this case, SFML's).

Anyway, I guess I am just still surprised that there aren't any open source libraries that can really compete with OpenAL with a more permissive license. It is not that I am against open source projects (if I do the wrapper thing, it will be open source), but I don't like it when the open source libraries try to prevent "closed source" projects from using them. That is just my opinion, and I respect anyone that thinks otherwise.

See... the thing is... the larger the effort that is required to be put into a library, the more it is worth in non-monetary terms. People often don't like giving things away, as you already know. Providing a library for "free" is not equivalent to giving it away for free i.e. without any license restrictions. The license that is often chosen in such cases is a strong copyleft. Instead of requiring you to pay money for the right to do whatever you want with the library, you "pay" by sharing your code with the community in return (in the case of GPL), or in the case of LGPL, you "pay" by promising the developer that any modifications (for better or worse) made to the library are shared back as well, which requires that such modifications can even be made to begin with hence the linking restriction. People seem to forget that before money existed, it was normal for people to trade goods with one another. Obviously, if you had an issue with offering something that someone asked of you in return for something they have, you wouldn't end up trading with them, no matter how much you complain. The same applies to software as well. Closed source projects complaining about the "viral" nature of strong copyleft licenses are for lack of better words, greedy and selfish. They want to benefit from the library without providing anything of interest to the developers (not money obviously) in return. If they want to compensate in money, some projects might allow for dual-licensing, so that is also not an excuse. I really cannot sympathize with them in this regard.

Given what I have just said, you will find that any kind of highly complex library is often proprietary or strong copyleft. They aren't things that people can do in their spare time like SFML is, hence they want their time to end up being worth something more than their own personal enjoyment.

In this case, I am willing to help improve YSE, since I want to use it. Isn't it better to have more developers (even "closed source" ones) involved with the open source project than to try and dictate what people would do with your code? I participate here because SFML helps me with my coding, and I want to help the project. The same will hopefuly happen with YSE as well.

P.S.: If all the LGPL license cares about is that you share your modifications with the community, there would be no need to prevent static linking. You could still staticaly link the modified library and share it's code. They enforce dynamic linking so that any software that uses the library can be "injected" with any modified version of the library, and that is just wrong, in my opinion.

I want to discuss the OpenAL API wrapper thing, specially its possibility of integration to SFML, and I am willing to code the wrapper even if nobody else is, as long as it isn't much trouble.

Like I have said multiple times already, wrapping YSE in an OpenAL interface makes no sense if its API can be used directly in the SFML code anyway. Rather than writing the wrapper, you should probably focus on understanding how SFML's audio code works, so you can implement it using YSE if you so desire.

If I do that, I would be dropping SFML Audio entirely. I have code using SFML Audio, so insted of porting all my code, I would rather code an OpenAL API wrapper, so that more people could use it and I could keep my SFML code as it is now.

First, can someone (Laurent, eXpl0it3r, or someone else that knows SFML's use of OpenAL) confirm that the current OpenAL Soft API hasn't changed from the Creative OpenAL one on the following link, and that implementing those functions would be enough for SFML Audio to function?
http://open-activewrl.sourceforge.net/data/OpenAL_PGuide.pdf

Code: [Select]

...

Thank you! If those are all of the OpenAL functions called by SFML, they are all on that PDF. I will analyze the YSE code now, to know how much trouble I would have to strip JUCE and replace it with a library with a more permissive license for the IO functionality on the main platforms.

[Laurent]

1. Don't forget that you can use your own statically linked OpenAL-Soft, instead of the one SFML provides, if your own code is LGPL.

2. More platforms: OpenAL-Soft already does what you describe, if you want to port SFML to more platforms then the solution is just to write a new platform back-end for OpenAL-Soft.

3. OpenAL wrapper for YSE: you'll end-up with an OpenAL implementation, what difference would it make then?

4. MIDI synthesis: it will most likely be added soon as a sfml-audio plugin (I've found libraries that can convert MIDI and other tracker formats to sampled audio).

[Tex Killer]

1. Don't forget that you can use your own statically linked OpenAL-Soft, instead of the one SFML provides, if your own code is LGPL.

My own code is closed source.

2. More platforms: OpenAL-Soft already does what you describe, if you want to port SFML to more platforms then the solution is just to write a new platform back-end for OpenAL-Soft.

Sure, but the OpenAL API, although small, is still a pain in the ass. I think it would be just easier to implement some simple IO functions for the platform, but you are right.

3. OpenAL wrapper for YSE: you'll end-up with an OpenAL implementation, what difference would it make then?

I would be able to create a simple interface for the platform specific code inside YSE, would be free from the LGPL license and would have YSE ready for using any of its other functions. Those reasons are enough for me to at least try to implement the wrapper.

4. MIDI synthesis: it will most likely be added soon as a sfml-audio plugin (I've found libraries that can convert MIDI and other tracker formats to sampled audio).

Nice to hear it! You were once concerned about the libraries size, did you find some alternative for the big instrument base?

[Laurent]

Sure, but the OpenAL API, although small, is still a pain in the ass. I think it would be just easier to implement some simple IO functions for the platform, but you are right

I'm not talking about the OpenAL API. It's implemented in OpenAL-Soft, fine. I'm talking about the internals of OpenAL-Soft itself: it already has a smaller subset of platform specific functions for low-level input/output. You would just have to port these functions to make it work on a new platform. No need to reinvent the wheel.

would have YSE ready for using any of its other functions

Not through SFML, then?

You were once concerned about the libraries size, did you find some alternative for the big instrument base?

No, one still has to somehow get the instrument database to play MIDI, whether it is installed by default on his system or copied with the musics. But it would be an optional plugin (maybe not even official), so it wouldn't be shipped with the precompiled SFML libraries.

[wintertime]

Why dont you stop arguing already Tex Killer? You painted yourself into a corner and by endlessly repeating the same disproven arguments you will make yourself only look worse without ever being able to convince people of doing unnecessary free work. Just change your own code to use YSE or whatever.

Btw., isn't YSE using JUCE and with JUCE beeing GPL your own code would be linking indirectly with GPL code instead of LGPL OpenAL soft? This would mean you would be "worse off" and need to open source your code, as GPL doesn't even have that dynamic linking exception.

[eXpl0it3r]

To me it seems there are quite a few misconceptions going around here. So let me try to clarify a few things:

YSE is not an audio back-end, it's merely a highlevel API over JUCE and JUCE does the hard work. Just replacing OpenAL with YSE or writing a OpenAL API wrapper for YSE won't solve anything regarding licesing issue, in fact it would get even worse due to JUCE being GPL. Thus one first needs to replace JUCE, which will not be an easy thing, especially for all platforms.


The way SFML currently works:

SFML API -> OpenAL API -> OS API (-> Internal API) -> Driver

For Windows this could for example look like (as far as my understanding goes)

SFML API -> OpenAL API -> DirectSound API -> WinMM API -> Driver

What Tex Killer now really wants is either one of these two positibilites:

1) SFML API -> OS API (-> Internal API) -> Driver
2) SFML API -> Another Third Party API, but not OpenAL -> OS API (-> Internal API) -> Driver

If you really think about replacing JUCE with the OS APIs for YSE, then you'll very soon realize that this work is not something we want to do and maintain in SFML itself, thus 1) won't happen.
As for 2) what's the point? There's no comparable library out there, as such you'd have to write your own (say you adapt YSE) and thus you'd essentially implement all the OS API calls (like OpenAL already did), just to end up with a different high-level API. Wouldn't it be waaaay smarter to use the standardized and well-known/used API (i.e. OpenAL specification) and simply write a new implementation for it, which you then can release under whatever license you'd want?
If there's really a platform which doesn't support OpenAL, it would still be a lot better to modify OpenAL itself, instead of investing days of work to get a library that supports all the platforms OpenAL supports + the one you want to support. Then the whole OpenAL user base could benefit from it as well. Analogically if you notice that you missed a feature in your library code, you don't go and throw the code away and start from scratch, but you simply add it to the existing code base.


As for LGPL and linking. The way I understood the license is, that you can link it however you want. The only thing you have to guarantee is, that a newer/different version of the LGPL licensed library can be linked. Thus you could also just provide the object files of your application, so someone can link in a newer version of OpenAL. Of course this would still allow for linking modified versions of OpenAL.


If you're concerned about asset leaks through library replacements/injections, then you'd probably would have to talk to the drivers directly or even write your own driver, because as shown above, e.g. OpenAL on Windows uses DirectSound, which again is a library that can be replaced and DirectSound uses WinMM, which again is a library that can be replaced and depending on your driver, the driver might also be built as library and would thus be replaceable, etc...
As binary1248 indicated, playing around with the RAM is rather easy with the right tools, so you're largely misjudging the difficulty of one vs the other task.
And when it comes to GPU memory, things get even easier. Not to mention the numerous DirectX or OpenGL injectors out there.