OpenAL-soft for AmigaOS

@Salas00
Tried with your new libopenall + new libalut which you upload a few days ago: still same crash. But with older libopenall and old or new libalut no crash.

@kas1e

Have you tried disabling the three lines before alutExit?



These should be unnecessary and may cause problems as alutExit() does more or less the same when called later in the program.

@Salas00
I back to the issues again (with a crash on exit), and that what I got so far:

If I compile code with the latest openal/freealut, then on exit I have 3 crashes at the same time: 2 crashes at in aluxMixData() and after that crash in __NewlibCall() and one crash in alc_cleanup(). None of which called directly from the game.

If i fully comment out all the code inside of that function:



Then nothing changes at all. Like all the code called not from the game itself.

Then I tried an older version of openal (some 7-8 years old openal) with also fully commented out that block. And this time i have only one crash, which is come from ReleaseALC->alcDestroyContext->__NewlibCall. All of these calls are also not from the game itself.

The only way how I can get rid of this crash is to use an older version of SDL2 (yeah, strange) + that old version of openal. How SDL2 can have an impact here I don't know because openal/alut didn't use anything from SDL2, but maybe it just causes memory shifts, and so bug somehow autohides.

But then why on exit, when we remove the full part about freeing audio resources from the game's code?

@kas1e

It is probably relevant information that SDL2 opens (and closes) newlib.library. This is because otherwise I couldn't make libSDL2-2.0.so working when opened via elf.library. For example RebelSDL opens SDL2 this way if I understand correctly.

@Capehill

Good idea!

As I compile everything statically, I just remove open/close of Newlib in the latest SDL2 and compile it like this. And everything works then with old OpenAL fine again! No crash on exit! Even if I put the game's code about cleaning alut/openal resources back.

What did it mean then? Wasn't the opening of newlib happens in older SDL2? If it something fresh (like from last year's addon), then it can explain something. Maybe OpenAL doing something with newlib too?

@Salas00
Through, even if I remove the opening of newlib from SDL2, it still crashes with new OpenAL on exit, and in console, I have "Al lib: (EE) alc_cleanup: 1 device not closed". But once I remove that block:

Quote:

I still have crashes, and in the console have words that 2 devices not closed.

In other words, old OpenAl seems ok there, just to fix the crash I need to remove open/closing of newlib in SDL2. New OpenAl still crashes: with original game code 1 device not closed, with commenting out cleaning of resources from game's code 2 devices no closed and crashes too.


Anyway, currently, I can just use old openal, with removing opening/closing of newlib in SDL2.

@kas1e

SDL2-OT:

I *guess* SDL2 doesn't need to define IExec and INewlib when linked statically since these symbols should be provided by some of the startup files, right?

Dynamic linking I need to check. Things seem to change when migrating to newer compilers and sometimes they cause lots of headache.

So maybe IExec / INewlib can be only defined for libSDL2.so if they are still required (GCC10).

@Capehill

IExec and IDos is already opened for normal programs, if writing real Amiga libraries you need to open the libs, as then the normal startup code is not called.

When you write SDL program you need to call init_sdl(), it can good place to check if the library was opened before or not. Then you call SQL_Quit(), if SDL needed to open libs, only then should it close the libraries.

.so files are linked when program starts, so it should be no different to .a file.

As programmer I do not wont to worry about what SDL has opened or not.

BUMP

I was wondering if we could get surround sound support in OpenAL (and SDL2 if the limitations is there). Some games like Doom3 would benefit greatly in gaming experience.

And why else do we have surround capable hardware

Surround sound for the hardware supported video players would be great too. I know that it is on the todo list for entwickler-x. Not sure about how far up on the priorities list

@Capehill

>IExec and IDos is already opened for normal programs, if writing >real Amiga libraries you need to open the libs, as then the normal >startup code is not called.

As to IExec this is only true for normal executables.

For .so Libraries this is not true. So it is a good idea if a linker library using AmigaOS functions initializes IExec so it can be used inside a .so library without having to recompile the linkerlib with an "adaption" (this is what I did to get gl4es running with the Heretic 2 Renderer for example - modifying the gl4es source code to initialize IExec correctly - of course I also gave my changes back to the project and they integrated it).

IDOS has no such issue though. It is only for IExec where this problem exists.

Steffen

@TheMagicSN
If you can't access the IExec provided by the C library startup code for the main executable in the .sos used by the executable there may be another bug in elf.library, or the current versions of GCC or binutils.

@LiveForIt
Quote:You may have to open some other libraries, but not IExec since you get that (or SysBase) in the library init function.
There should be nothing at all in AmigaOS 4.x where don't either get IExec nor SysBase (IExec = SysBase->MainInterface) and have to use the DSI exception handler to get it reading address 0x4 instead.

It looks like OpenAL does support mono and stereo only. Hopefully someone who is familiar with OpenAL can look at this as well.