Internal audio latency

[triplefox]

When running TIC-80, across multiple platforms(Windows desktop, HTML5 player, Android), I always notice small pops and creaks when it plays sound, symptoms of frequent buffer underruns during audio playback. The current method it uses is to call SDL_QueueAudio from within the render tick and blit everything that has been rendered in that frame, which leaves the program heavily reliant on making every frame deadline every time.

Most audio programs run a separate audio thread with intentionally added frames of latency to smooth this out: instead of handing over all the samples that have been constructed right at that moment, they're repackaged into fixed-size audio frames for API consumption, and the renderer stays ahead of the API by a target number of frames. This adds a margin of safety, and the fixed size plays better with most audio APIs. Many apps also expose some user configuration options for buffer sizes.

[nesbox]

In few words, we have to add empty buffer to the audio frames to allow slightly late for the sound system...
I'll try to add this, thanks.

[borbware]

probably related to this: on my machine, if i leave tic-80 running for a long time, audio latency keeps building up, and before long, audio is played with a latency of several seconds. (0.70.6 pro, win10)

[nesbox]

Does your machine go to sleep mode during this time?

[borbware]

no, it does not! It happens steadily and gradually if I just keep TIC-80 open for a while (e.g., if it's on for a couple of hours, there is a guaranteed audio latency of a few seconds)

[nesbox]

need investigation, thank you @borbware

[runlow]

Experiencing the same problem as @borbware is describing but on Archlinux.

If I open a game or the music tracker for too long then I have to close TIC-80 and open it again. If I don't do this every 10 minutes or so the sound delay becomes greater and greater. It doesn't take hours - few minutes is enough. This makes the music tracker or any game with longer gameplay unusable/unplayable for me.

When I run TIC80 from the command line it would slowly keep showing the following message in the terminal but the program would keep running
ALSA lib pcm.c:8545:(snd_pcm_recover) underrun occurred

From alsa documentation:
"The underrun can happen when an application does not feed new samples in time to alsa-lib (due CPU usage)"

I've noticed that when I run pulseaudio this delay problem seems to go away and the sound on TIC-80 seems OK but running pulseaudio in turn causes other problems with other programs that use the soundcard so I would prefer not to run pulseaudio.
For example if something is already playing sound with pulsaudio running and I start TIC-80 then after closing it - TIC-80 still keeps running in the background and I have to type pkill -9 tic80 to force it to end the process.

If anyone has suggestions for workarounds or patches please let me know. I was thinking about maybe wrapping the tic80 command in a shell script which checks if the sound card is in use and if it's not then starting and exiting pulseaudio with tic80, and otherwise not starting pulseaudio it at all. Another idea was that whatever pulseaudio is doing that makes the delay go away could be maybe accomplished somehow with alsa-tools. I could try to figure out how preparing samples for the sound card works (guessing it's this part here) and patch and build TIC-80 but it's a bit over my head.

Edit: I've made sure that everything that uses audio is using sdl or pulseaudio as the audio device and showing up with a moving bar on pavucontrol and this seems to prevent tic80 from not exiting correcty - as strange as this may sound. This may be a good enough workaround for now. Hope this helps someone.
Edit2: installing the pulseaudio-alsa package may have helped. Not an ideal solution but I think it works well enough for now.

@nesbox please add a "bug" label on this one as making the audio work correctly is not an enhancement in my opinion

[terrybrash]

Same problem as @borbware. Leaving TIC-80 open and not interacting with it for maybe 5-20 minutes will cause long audio latency that can only be fixed by restarting TIC-80.

TIC-80: version 0.90.1723 Pro (9c38a80)
OS: Windows Version 10.0.19043

Related issue: #1199