Move to OpenAL Soft #18
Comments
|
I think this begs the bigger question of whether OpenTK should distribute native binaries, or be dependent on any non-system binaries. Personally I like that OpenTK is a managed-only cross-platform implementation. Come help us figure out what to do with this on OpenTKR-dev: |
|
I was thinking a little bit more along the lines of distributing with the installer, so as to avoid an exception being thrown immediately for any Windows users without OpenAL installed. |
|
OpenTK is a library for developers. IMO, how it is distributed is less important than how apps built using it are distributed. Today I can build a 3d program using OpenTK-GL and GameWindow on Mac, zip it with the platform neutral OpenTK.DLL, unzip it on windows (32bit or 64bit), and it runs. It's a CLR-only cross-platform solution. OpenTK-AL already breaks this on windows, because windows doesn't come with OpenAL. Personally I'd like to fix this and make OpenTK a 100% CLR cross-platform solution for Audio as well. This would mean either implementing OpenAL in CLR (mapping to whatever native libraries are available), or removing OpenAL and supporting a simpler Audio abstraction which can be made cross platform. |
|
@jeske I totally agree with you. It would be nice to keep OpenTK as complete (enabling Graphics, Audio and Window management) and as independent (cross-plattform and no third-party libraries) as possible. |
|
The installer already downloads OpenAL and (optionally) NShader, I don't know if anyone is going to really ever use that again, but I was saying we should update that: https://github.com/andykorth/opentk/blob/master/Installers/Nsis/opentk.nsi#L180 OpenAL Soft is a package on most linux distros, but I'm not sure where OS X stands. If OS X has a built-in OpenAL implementation, I think it's cross-platform enough for our use. Writing a CLR implementation of OpenAL would, IMO, be a large enough project to be considered it's own library. And as far as cross-platform audio libraries, everything else I've seen is either worse or on equal footing with OpenAL in terms of being commonly installed/portable. Assuming OS X doesn't have OpenAL, PortAudio is equally portable, binaries would have to be distributed on Windows and OS X, and it is a package on most Linux distros. |
|
OpenAL comes with OS X, and has for as long as I remember. It just works out of the box with OpenTK, at least that has been my experience.
|
|
For me, OpenTK-GL is currently filling a niche more like Java3D, where the same single EXE/DLL directory runs on Mac/Windows with no native libs and no requirements to install native libs. To extend this capability, I'd prefer to add basic cross-platform audio and less game centric window support, more like GLUT/Ghost/EGL. That said, I am drawn by the alure of including and wrapping more native libraries, such as bullet physics and OpenVDB -- more like Tao does, but in a more managed friendly interface like OpenTK. Perhaps a good route would be to draw a line of separation between a cross-platform profile OpenTK-portable (OpenGL, GameWindow, GLUT/Ghost-ish windows, newly built basic Audio), and a per-platform native libraries profile OpenTK-native (OpenAL, OpenCL, ODE, Bullet, OpenVDB, etc). |
|
Technically OpenGL still needs you to install native libraries on Windows/Linux. (I understand that Windows comes with an OpenGL 1.1 implementation, but it's unusable for anything beyond a single spinning cube). Telling a Windows user to install OpenAL is essentially the same as telling them to install their graphics card drivers. Personally, I think writing your own audio abstraction library is a massive waste of time to avoid shipping/telling users to install a single binary on Windows. As for where the line is drawn, I think that the it should be drawn at Khronos-style APIs parsed from .spec files. As I mentioned in the mailing list, other libraries are structured differently and may be better served by exposing a different type of API on the C# side. For example, with SharpFont, I could have just exposed a static FT class with properly stylized names and enums, and I did in the beginning, but I found that FreeType is essentially an object-oriented API made to work with C structs, so I made my API expose objects with instance methods that chain off to the extern functions. I personally think all those other libraries would work better as separate libraries. But if we do decide to include a lot of other libraries, I think it would be best that they be split into separate assemblies, possibly with a common assembly that includes the math classes and a few helper classes. If that happens, I'd be happy to merge in my FreeType wrapper as part of OpenTK. And unless I'm mistaken, OpenCL should be included in OpenTK-portable as well since graphics card drivers now include an OpenCL implementation (though I've really been able to test on NVIDIA, so that may not be true for AMD/Intel). |
|
Good points about OpenGL driver installs. You've convinced me my cross-platform aspirations are too aggressive. Stepping back a bit, I think it should be easy to distribute OpenTK apps in a self-contained way for supported desktop platforms (mac/windows/linux). In this sense, redistributable native libraries like OpenAL-Soft are easy, since OpenTK and the end-app can install them... It's the non-redistributable stuff, like the raw OpenGL drivers which we'll have to prompt the user to install on their own. I'll have to think on this a bit, but I like that this creates a clear path to include things like ODE, OpenVDB, SharpFont, and others (as separate and nicely wrapped assemblies). On a related note, I can see the sense of MonoGame providing XNA and mapping that down to whatever is available. This way they can map XNA's slightly simpler model down to whatever is on the platform. I wonder if there would be value to sharing a cross-platform managed window binding (like GLUT/EGL/Ghost) which could allow MonoGame/XNA to branch out beyond a "game window". |
|
it seems you forget the primary targets that are iOS and Android regards, On 16/08/13 06:29, David Jeske wrote:
renan jegouzo (YoY) |
|
I'm not forgetting mobile, it's just not why I use OpenTK. My need for OpenTK is very desktop centric. I think it's going to be quite a while before mobile-operating systems replace computers for 3d modeling and other 3d content authoring. Also, WRT this discussion, all the dependency issues are moot for mobile, since it's basically embedded system development. |
|
the thing, it's not what you do, it's what users do. me I use OpenTK in all my projects for all targets. renan On 17/08/13 08:45, David Jeske wrote:
renan jegouzo (YoY) |
|
I think you have to support your statements regarding target platforms some more in this company. I also use OpenTK for Desktop-Development only at the moment. And I also do not think that the usage of PCs will decline in the future. Certainly, things may change, but I am thinking of the steambox for example, which will bring the PC to the living room as gaming platform (and I would say there is a good chance of doing so successfully, knowing Valve.) On another point, I would second that any revival project should not start including other libraries in the core of OpenTK. To me, getting the existing features to work on all platforms, and fixing any issues with them has a much higher priority. |
|
I just says that for now OpentTK works well on Android and iOS, and I renan On 17/08/13 10:15, amulware wrote:
renan jegouzo (YoY) |
|
Oh, as far as I understand, nobody is doing that. I think it is simply not the main concern right now, given that there are more serious ones, for example regarding OSX and OpenCL. So, while we are certainly keeping the mobile platforms in mind, it is just not relevant for this discussion, so no worries! |
|
@renanyoy - This discussion is taking place on on an issue-tracker issue called "Move to OpenA-Soft", which is discussing switching to a bundled OpenAL-Soft instead of legacy OpenAL on MS-WIndows. We're not talking about Android and iOS targets here, because they are not relevant to this issue. If you'd like to talk more broadly about OpenTK and mobile, I invite you to join the mailing list amulware posted. It's also worth noting that OpenAL-Soft is not a great solution for Android/iOS, since it is LGPL and LGP/GPL require the ability to relink, which is problematic for binary-only embedded (mobile) deployment. Perhaps this is another good reason to look at different audio API solutions for OpenTK. While I personally don't use OpenTK on Android/iOS, they are obviously important targets. However, your prediction about PCs mostly being replaced by tablets in a few (3?) years, are at least 5-15 years premature. Mobile operating systems have yet to produce acceptable versions of mainstay applications like Office, Photoshop, or even a fully working web browser. So far they are driving computer-penetration to 100% more than PC penetration to zero. I expect this to change slowly over time, but not in 3 years. As for when C#+OpenTK is viable for mobile, that's a different story. There is much less headroom there for GC. Unity only uses C# for scripting their C++ engine and it's already tough to avoid GC pauses. |
|
it's already done, more persons use tablets and smartphones than computers.. OpenAL is actually implemented on iPhone so it just need the wrapper. yes, all I.T. persons will continue to use computers, but I.T. doesn't renan On 17/08/13 17:16, David Jeske wrote:
renan jegouzo (YoY) |
|
@renanyoy - Can you please keep discussion here related to the title of the issue (Move to OpenAL-Soft), or open an issue which is a specific problem you are having? There is already an OpenAL wrapper in OpenTK. https://github.com/jeske/opentk/tree/master/Source/OpenTK/Audio Let's please take this discussion about mobile vs desktop to the mailing list. It does not belong in a bugtracker. |
|
my only concern was this sentence in a previous post "Stepping back a bit, I think it should be easy to distribute OpenTK apps in a self-contained way for supported platforms (mac/windows/linux)" that why I told to don't forget android and iOS as target platforms. otherwise I think it could be be nice to add OpenVG in OpenTK, I have already made a wrapper for MonkVG that is a software version of OpenVG: https://github.com/renanyoy/MonkVG-Sharp |
|
The only way to distribute for mobile is as a self-contained installer, since there are no separate system library installs. I clarified my previous comment to: "Stepping back a bit, I think it should be easy to distribute OpenTK apps in a self-contained way for supported desktop platforms (mac/windows/linux)" MonkVG looks nice, and it is BSD licensed so it is very compatible with mobile projects. I'll take a look at your MonkVG-Sharp when I figure out the high-priority OpenTK stuff. |
|
@jeske Minor nitpick from your 3rd-to-last, there is no "legacy OpenAL" on Windows, people generally use the proprietary Creative implementation, including the OpenTK installer. And we could generate OpenSL ES bindings for the Android users... And at least with Android, I think you can still use LGPL libraries like OpenAL-Soft, since you can dynamically link to native libraries, though it may be a gray area since you can only distribute a single .apk file... That's something I'd ask either a lawyer or the OpenAL-Soft developers. There is this though: https://github.com/AerialX/openal-soft-android |
|
When I use the term "legacy", I mean any software which is no longer maintained and updated. It sounds like this propritary Creative implementation was last released in 2008, so I think it meets my definition. Is there a current and updated OpenAL implementation for windows (for any hardware) besides OpenAL-Soft? Regarding Android/iOS, the issue with LGPL is that it requires you allow a user to relink your binary software against a new version of the LGPL library. This would require authors to distribute a re-linking package, enabling consumers to re-link or re-bundle it with a new OpenAL-Soft build. This might be okay for some developers, but it's not okay for all devs, so I'd prefer to find an MIT/BSD-ish solution if at all possible. Update: I'm friends with a company that provides a re-linking kit for their iOS app to satisfy the LGPL. I'm going to ask them how they feel about it. |
|
Just wanted to let you know that OpenTK now bundles Windows builds of OpenAL Soft (and a few other useful libraries) inside its Dependencies/ folder. The old OpenAL installer from creative will be completely removed from the installer. Apps are expected to deploy the necessary dependencies within their installers. IIRC, every platform outside Windows supports OpenAL out of the box. It might be possible to build a fully managed version of OpenAL Soft using C++/CLR with the /clr:pure option and a small trick. This should work on non-Windows platforms but it will probably not perform adequately. |
I don't know when this happened, but for at least a few days, the
connect.creativelabs.comdomain has disappeared. This site hosted the OpenAL installer and some helpful PDFs. At the moment, the only way to get OpenAL is via those sites that aggregate software (more than half of which just link to the now-dead site) and re-uploads posted on various websites.Leaving users to get OpenAL this way is a potential security issue. People can modify the re-uploads of the installer to include malicious software.
The Creative implementation is (was?) proprietary anyways, OpenAL Soft is LGPL, which means that we should have no problem redistributing in binary format.
I'm going to be very busy these next few weeks, otherwise I'd do it myself and just submit it as a pull request. It shouldn't be too hard, though. OpenAL Soft is supposed to be a drop-in replacement.
OpenAL Soft website
The text was updated successfully, but these errors were encountered: