MacOS M1 OpenAL error with generating buffer
Description
I already have been written about that on forum.
While gaming after some time (I think buffers stack overflow) AL.GenBuffer starts generate InvalidValue error and returns 0 new buffer's index, it causing new errors because engine can't upload audio.
After debugging I noticed that nowhere calls AL.DelBuffer, but source freeing calling. I think, it is a clue.
Maybe TTSless servers devoid of this problem because there are fewer audio upload calls. But I think, it needs changes in engine.
https://forum.spacestation14.com/t/macos-open-al-al-genbuffer-returns-0-null-after-some-time/9840
I tried to find a cause. My guess turned out to be true: default MacOS's realisation of OpenAL has the limit is 1023 buffers. Engine doesn't free up buffers, because of it OpenAL after a lot of created buffers can't continue to do it.
How I got this? I made a test. I wrote a program with C++, firstly I used default OpenAL
After I used OpenAL Soft (Installed with brew):
There is the limit as you can see.
The problem has two ways to solve it: freeing up buffers or use OpenAL Soft solution. But both solutions have their own problems. It needs rewriting anyway. I didn't find how to make OpenTK.OpenAL to use OpenAL Soft.
but as an alternative, use Silk.NET.OpenAL.Soft instead OpenTK
but as an alternative, use Silk.NET.OpenAL.Soft instead OpenTK
This is not that easy
Blocking this on #4997
In this case, I suggested a fix. It will be the simplest solution at the moment.
@Sh18RW Just curious, does the PR you made (#5735) significantly reduce the number of crashes on M1 macOS or is it not at all relevant to this macOS issue?
Just curious, does the PR you made (#5735) significantly reduce the number of crashes on M1 macOS or is it not at all relevant to this macOS issue?
That fixes the audio breakdown, reducing the number of errors in the console. However, I am not sure that this will make much difference to the crashes. As far as I know, the crashes were related to the graphics library, is it?
I'm looking at this now.
After debugging I noticed that nowhere calls
AL.DelBuffer, but source freeing calling. I think, it is a clue.
Correct. TTS-based servers have always been a system that can't work due to lacking engine support. It's one of the many reasons it's nowhere close to being upstreamable.
Closing since OpenAL Soft is now in.