Problems with building orbiter because of irrKlang

[BipBop]

It seems that irrKlang is not available for downloading anymore and because of it cmake can't generate orbiter's visual studio project properly. I've already opened issue on github.



CmakeLists.txt in sound submodule uses this link:
https://www.ambiera.at/downloads/irrKlang-64bit-1.6.0.zip



And if you try to download irrKlang package from official site:

 

[Urwumpe]

Maybe you should wait a few days, this looks like a website error to me. Irrklang pro should require licenses, but not the regular Irrklang for non-commercial projects.

 

[Gondos]

This kind of lib is a ticking timebomb, we should probably start making plans to replace it.
I already did some prototyping with libsndfile and OpenAL in the past, but it lacks the neat asynchronous file loading/playing of irrKlang.

 

[Lucy]

For a short-term fix, I shoved both bitnesses of Irrklang into the OHM digitalocean Space and set the cmake lists to pull that version instead.

Yes it's trading the availability of one site for another, but it's definitely a quicker resolution than moving off the lib entirely.

Pull irrklang from self-hosted mirror by Xyon · Pull Request #594 · orbitersim/orbiter

The original source download for these files is no longer available, which causes the build to fail. This is a short-term fix. Fixes #593

github.com

 

[Gondos]

For a short-term fix, I shoved both bitnesses of Irrklang into the OHM digitalocean Space and set the cmake lists to pull that version instead.

Yes it's trading the availability of one site for another, but it's definitely a quicker resolution than moving off the lib entirely.

Pull irrklang from self-hosted mirror by Xyon · Pull Request #594 · orbitersim/orbiter

The original source download for these files is no longer available, which causes the build to fail. This is a short-term fix. Fixes #593

github.com

Not sure this is compatible with their license :

The contents of the irrKlang distribution archive may not be redistributed, reproduced, modified, transmitted, broadcast, published or adapted in any way, shape or form, without the prior written consent of the owner, Nikolaus Gebhardt.

The irrKlang.dll, irrKlang.so and libirrklang.dylib files may be redistributed without the authors prior permission in non-commercial products, and must remain unmodified except for compressing the file.

 

[Lucy]

Oh, of course it is. Silly of me not to check that first, I suppose. I do love software licenses that basically make products utterly unavailable to you if something breaks on one person's computer. Sigh.

Other option is just not to build XRSound if it's unavailable, or to leave the builds broken. I'm not a big fan of either approach.

 

[n72.75]

I won't get the free-software soap box, nor does it solve any immediate problem....however virtually all incompatibility problems in Orbiter (old addons, old versions, etc) stem from, at least in part: "non-free" or "links to non-free".

Isn't there an SDL library that does async audio? I'm sure it's hardly a drop-in with comparable API calls.

 

[Urwumpe]

I also think the maintainers of Orbiter should watch their supply chain carefully. It might be annoying to expect that, but in the end, they have the final responsibility for it.

And yes, I am surprised that IrrKlang has a more restrictive license than Irrlicht, despite coming from the same person...

 

[Lucy]

I also think the maintainers of Orbiter should watch their supply chain carefully. It might be annoying to expect that, but in the end, they have the final responsibility for it.

Talk is cheap, send patches. It goes without saying that we as maintainers are responsible for what's in our software.

Even free software becomes incompatible sometimes; the specific problem here is the source lib becoming entirely unavailable at the whim of the original developer and there being no compliant mechanism for obtaining it. And since the license prohibits fixing that problem in an obvious way, the solutions are limited to "put up with it" or "use a different piece of software to handle this" - once is obviously less effort than the other, but moving to a different external library will just move the problem somewhere else unless its license is more amicable to actually being used in a software project.

I'll have a look for alternative libs to replace irrklang with, but I sincerely doubt any of them will be a drop-in replacement and the XRSound code isn't code I'm familiar with, so this is far from a quick fix. In the meantime the only compliant solution is to disable building XRSound entirely, which will stop us pulling in the dependency altogether. I guess I will have to do that so we're not violating the license again, and for the time being orbiter development builds will not have a sound module built (you can still build it yourself though, I suppose).

 

[Urwumpe]

As I said, it might be annoying to expect. And if your solution to accountability and decision-making is making everybody responsible for "Sending patches", fine. Lets patch Orbiter to hell. Everybody gets a turn.

Also, the license was likely never changed at all, it and the risks it contained were just accepted. And now we simply pay the price. Also.... what about trying to permit multiple sound provider modules, that are late linked into Orbiter? Even if we should want to use only one as default, such an architecture could make big changes still easier to handle. And we could permit a longer development time for a Irrklang replacement, like for example using XAudio2 (Which at least wine supports additionally to Windows) or OpenAL (which Win, MacOS and Linux can use) directly.

I don't think we can get a IrrKlang replacement done in a short time - especially I can't even estimate yet, how long I would need for that.

 

[jarmonik]

Could we simply contact them and ask for a license assuming, that it's free, and hopefully something that we could redistribute. At least for a time being until we got an open source replacement ready. Starting to pay for a license that's no go.

 

[Lucy]

Also, the license was likely never changed at all, it and the risks it contained were just accepted.

Yes, specifically the risks it contained were accepted by the original developer of XRSound who implemented the library back when that was a separate project, and now it's incorporated into the core and we are where we are. This doesn't really matter.

And if your solution to accountability and decision-making is making everybody responsible for "Sending patches", fine. Lets patch Orbiter to hell. Everybody gets a turn.

I just mean if you spent half as much effort actually contributing to the project as you do filling up the discussions around it with empty - yet somehow still unhelpful - comments, we could actually benefit from your input.

Could we simply contact them and ask for a license assuming, that it's free, and hopefully something that we could redistribute.

Costs nothing to try, almost certainly worth a shot - at least in the immediate term. Turns out disabling XRSound isn't actually as straightforward as flipping the flag off in the cmakelists - there's a hard dependency on it in the luainterpreter that causes the build to fail when XRSound isn't being built. I'd like to fix that regardless of the sound library in use, because I'm not a fan of the coupling there, I'm hoping to see if I can have the XRSound code in there excluded when the flag isn't set. Fixed this now, the XRSound flag works as intended and is now set OFF by default - meaning the debug builds no longer ship with it built. Previous change was reverted and the irrKlang files have been removed from our platform, so we're back to complying with their license. This means that right now, if you want a debug build of Orbiter with XRSound, you'll have to build from source and enable the cmake flag for it yourself (and provide it a copy of irrKlang to link against).

Also.... what about trying to permit multiple sound provider modules, that are late linked into Orbiter?

This is still possible, I'm pretty sure, you would just disable XRSound's module and load your other one using the module system - the same way orbitersound always worked. I don't think we'd need to change anything for that; this is just about what's built and shipped as part of the core simulator.

 

[JDat]

+1 reason to migrate to SDL2 or SDL3

 

[Lucy]

+1 reason to migrate to SDL2 or SDL3

I vaguely recall there being some other things that could be replaced with SDL too but I forget what; regardless, it's certainly a big job to replace.

 

[Gondos]

SDL is planned to replace the DirectInput and Windows API.
At the moment the biggest trouble I have with that is how to handle dependencies. Either we compile it ourselves or we use some precompiled binaries.
I'm not sure what's the usual way to include SDL in a cross platform project.

 

[Lucy]

SDL is planned to replace the DirectInput and Windows API.
At the moment the biggest trouble I have with that is how to handle dependencies. Either we compile it ourselves or we use some precompiled binaries.
I'm not sure what's the usual way to include SDL in a cross platform project.

Compiling it ourselves is probably the option with the longest lifespan, since we're not depending on someone else to do it for us. But dependency management in C++ is I think still something of an open headache. I forget how much I appreciate tools like rust's cargo - wonder why they don't exist for C/C++

 

[dbeachy1]

FWIW, the license on the irrKlang GitHub page hasn't changed, and still says (emphasis added):

The irrKlang.dll, irrKlang.so and libirrklang.dylib files may be
redistributed without the authors prior permission in non-commercial
products, and must remain unmodified except for compressing the file.

So, as I read that, it still is within the terms of the license to rehost (redistribute) irrKlang.dll, irrKlang.so and libirrklang.dylib. (And in fact, legally speaking, the original files and binaries retain their original licenses terms indefinitely -- only newer versions of the software could potentially have more restrictive license terms, if the author wishes. But the author cannot retroactively restrict the license terms for existing binaries and files that were previously released under their original license terms). XRSound uses irrKlang.dll on Windows, and it doesn't require anything from the Pro version of irrKlang. That paid archive includes, among other things, the static version of the irrKlang code that can run without irrKlang.dll. But XRSound only uses the free version of irrKlang, which requires irrKlang.dll.

In order to use a .dll file, the application being built has to compile using the import library (.lib) and .h include file(s) for that DLL. And those files are all in the public GitHub repository for irrKlang. What if the Orbiter build script would just pull the irrKlang .h and .lib files it needs to link with irrKlang.dll from the irrKlang GitHub repository (git clone https://github.com/jonas2602/irrKlang works for me locally), while pulling the redistributable irrKlang.dll from the Orbiter repository? That way, nothing from irrKlang is being redistributed except for irrKlang.dll, and we aren't rehosting any irrKlang files except the redistributable ones spelled out in the irrKlang license.

EDIT: Also, it turns out the irrKlang redistributable binary files (irrKlang.dll, etc.) are already in the public irrKlang repository in the bin folder, at least the 32-bit versions of them.

 

[Matias Saibene]

SDL is planned to replace the DirectInput and Windows API.
At the moment the biggest trouble I have with that is how to handle dependencies. Either we compile it ourselves or we use some precompiled binaries.
I'm not sure what's the usual way to include SDL in a cross platform project.

I don't know if my contribution is useful or not, but here I found (and am following) some excellent SDL3 tutorials:
https://lazyfoo.net/tutorials/SDL3/index.php

I'm not sure if it explains the audio in depth yet (I think it does), but it might be helpful.

 

[JDat]

FWIW, the license on the irrKlang GitHub page hasn't changed, and still says (emphasis added):



So, as I read that, it still is within the terms of the license to rehost (redistribute) irrKlang.dll, irrKlang.so and libirrklang.dylib. (And in fact, legally speaking, the original files and binaries retain their original licenses terms indefinitely -- only newer versions of the software could potentially have more restrictive license terms, if the author wishes. But the author cannot retroactively restrict the license terms for existing binaries and files that were previously released under their original license terms). XRSound uses irrKlang.dll on Windows, and it doesn't require anything from the Pro version of irrKlang. That paid archive includes, among other things, the static version of the irrKlang code that can run without irrKlang.dll. But XRSound only uses the free version of irrKlang, which requires irrKlang.dll.

In order to use a .dll file, the application being built has to compile using the import library (.lib) and .h include file(s) for that DLL. And those files are all in the public GitHub repository for irrKlang. What if the Orbiter build script would just pull the irrKlang .h and .lib files it needs to link with irrKlang.dll from the irrKlang GitHub repository (git clone https://github.com/jonas2602/irrKlang works for me locally), while pulling the redistributable irrKlang.dll from the Orbiter repository? That way, nothing from irrKlang is being redistributed except for irrKlang.dll, and we aren't rehosting any irrKlang files except the redistributable ones spelled out in the irrKlang license.

EDIT: Also, it turns out the irrKlang redistributable binary files (irrKlang.dll, etc.) are already in the public irrKlang repository in the bin folder, at least the 32-bit versions of them.

How hard is to move from irrKland to something else? For example SDL2/SDL3 and forget these weird external dependencies.

 

[GLS]

If changes are needed, switching to something that works in both Windows and Linux would be a good idea...