Open EricDiCiv5 opened 5 years ago
Which version of OpenAL are you using, and what audio system (ALSA, PulseAudio, OSS, SoundIO)?
OpenAL does free the memory it allocates. On a modern system, ALC_OUT_OF_MEMORY
typically means system resource exhaustion rather than running out of physical memory (especially on Linux, which uses lazy allocation). If you're able to run this under a debugger (with debug info for libopenal), you can set the ALSOFT_TRAP_ERROR
environment variable to true
or 1
, which will cause the debugger to break with a SIGTRAP
. You can then get a backtrace to see where that error is being set, which will help me narrow down the issue.
I'm using 1.19.1 OpenAL version with PulseAudio as the device.
SuperTuxKart would sometimes have this error, the issue ended up being that too many sources were being allocated, because of a source not being freed. If you need more sources than the default 256, see https://github.com/kcat/openal-soft/issues/144#issuecomment-326712057.
By using 'pdb', the backtrace obtained is the next one:
`pi@raspberrypi:~/geopy/neo-6M $ sudo python3 -m pdb -c continue footsteps_8.py
AL lib: (WW) GetSymbol: Failed to load jack_error_callback: /usr/lib/arm-linux-gnueabihf/libjack.so.0: undefined symbol: jack_error_callback
AL lib: (WW) jack_msg_handler: Cannot connect to server socket err = No such file or directory
AL lib: (WW) jack_msg_handler: Cannot connect to server request channel
AL lib: (WW) jack_msg_handler: jack server is not running or cannot be started
AL lib: (WW) jack_msg_handler: JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
AL lib: (WW) jack_msg_handler: JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
AL lib: (WW) init: jack_client_open() failed, 0x11
AL lib: (WW) alc_initconfig: Failed to initialize backend "jack"
AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5007:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM default
AL lib: (EE) AlsaPlayback::open: Could not open playback device 'default': No such file or directory
AL lib: (WW) alcSetError: Error generated on device (nil), code 0xa005
Traceback (most recent call last):
File "/usr/lib/python3.5/pdb.py", line 1665, in main
pdb._runscript(mainpyfile)
File "/usr/lib/python3.5/pdb.py", line 1546, in _runscript
self.run(statement)
File "/usr/lib/python3.5/bdb.py", line 431, in run
exec(cmd, globals, locals)
File "
/usr/local/lib/python3.5/dist-packages/openal/alc.py(57)alc_check_error() -> raise ALCError(alc_enums[err][0]) `
AL lib: (EE) AlsaPlayback::open: Could not open playback device 'default': No such file or directory
This would be the reason. The PulseAudio backend fails to initialize (missing client library, or can't connect to the server), so it uses ALSA instead. The ALSA backend then fails to open the default device (and it seems ALSA is unable to parse its configuration). The OpenAL standard is pretty poor when it comes to what to report for an unavailable device -- there is no ALC_DEVICE_UNAVAILABLE
or similar -- so it gives ALC_OUT_OF_MEMORY
in lieu of a resource being valid but unavailable.
I had similar problem, but only when the sound card is doing something else, and the thing is running in a Python virtualenv. I'm not sure how this is going to help solving this issue though.
Recently I've been working on two programs which use the OpenAL API in the language of python in order to guide the user (one as a compass and the other as a gps).
Initially they execute it but suddenly at one point the program at the execution was not able to allocate some memory for the default device that openal is using, indicated in the traceback just like that:
Is there any way to free the memory of the openal buffers in order to allow the assignation of the default device into the openal memory?
P.S: Links to the two Python programs (compass first, gps last) https://github.com/gdsa1022/TFG_HRTF/blob/master/footsteps_72.py https://github.com/gdsa1022/TFG_HRTF/blob/master/footsteps_82.py