Games that require direct access to ALSA do not function/launch

[SheepyChris]

Summary

Several games, including newer supported mixes on pumptools, directly utilizes exclusive ALSA to output audio. If a program is utilizing it or PulseAudio, they will be unable to properly initialize. This is the case when launching said games through SGL, since it appears that it takes over audio for too long and games start to initialize before it is closed.

Expected behavior

Games launched through SGL should be able to directly access audio and work just fine.

Current behavior

Pumptools oriented games fail to boot when selected, while StepMania based games completely fail to obtain any audio drivers.

Steps to reproduce

1. Add a game to the SGL game list that utilizes ALSA exclusively.
2. Attempt to launch the game through SGL.
3. Game will fail to boot, if using the trap script SGL will reinitialize.

Context (Environment)

My machine is currently powered off, but if necessary I can obtain the logs and config files later. This issue was tested with SGL working properly on both alsa and pulse drivers.

OS version

MX Linux 21.1, Linux 5.10.0-14

[SheepyChris]

As a workaround, adding a 5 second sleep timer to each game's launch script makes them able to boot properly.

[voidderef]

Hey, thanks for reporting that issue. It's something I remember facing as well when I started with SGL. At that time, I couldn't reproduce the behavior properly and at some point, everything just "worked fine on my machine".

Taking a fresh look at that problem, it might be quite obvious that the process still has a claim on the sound device, because the game just issues exit(0) when you confirm selection of a game and it kicks off the corresponding script.

A cleaner solution would be to tell the main loop to exit which finishes the current update cycle and enters all the de-init code before actually exiting the application. That should free's the audio subsystem which should release any handles/claims on audio stuff on the system side.

/thoughts and notes for me or anyone who wants to pick this up as a contribution.

Please note that I haven't worked on this in a while, so I cannot make any promises when I have the time and energy to pick this up again.

[super-triangle]

I think I’m running into this on a MK9. Individual games start via single game pumpos configuration but fail to launch via SGL. I can even manually call the same script SGL’s games.lua points to, and that works fine.

Sleep workaround in the script doesn’t seem to help things over here. making sure I understood correctly, that was placing sleep 5 in the GAME_NAME.sh on the SGL side?

[SheepyChris]

I had setup SGL to run another script from ./start.sh which contained the sleep delay. I believe sleeping from the first script will still keep SGL active until not necessary anymore.

…

On Sun., Jul. 31, 2022, 1:46 a.m. Norah Smith, ***@***.***> wrote: I think I’m running into this on a MK9. Individual games start via single game pumpos configuration but fail to launch via SGL. Sleep workaround in the script doesn’t seem to help things over here. making sure I understood correctly, that was placing sleep 5 in the game.sh on the SGL side? — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDD6Y2ISML3IP57QLAZLCLVWYHMLANCNFSM5VQFJJFQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[super-triangle]

Closing the loop here, I looked closer in the logs and realized I had an entirely different problem: the scripts SGL was trying to run didn’t have exec permissions.