Internal audio latency #714
Comments
|
In few words, we have to add empty buffer to the audio frames to allow slightly late for the sound system... |
nesbox
added
the
enhancement
|
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) |
|
Does your machine go to sleep mode during this time? |
|
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) |
|
need investigation, thank you @borbware |
|
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 From alsa documentation: 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. 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 @nesbox please add a "bug" label on this one as making the audio work correctly is not an enhancement in my opinion |
The audio is synthesized in SDL_AudioCallback. At the end of a tick, SDL_LockAudio is issued, sound registers are copied to the part of memory owned by the audio thread, and then the audio is released with SDL_UnlockAudio.
Previously, the sound registers were used to synthesize fixed amount of sound after every TIC() and this was pushed to SDL. The problem with this approach was crackling if TIC() takes too long to reach 60Hz. In this fix, the sound registers are instead pushed to a ring buffer and the audio is synthesize in SDL callback to render audio. If the ring buffer does not have enough values, the sound synthesis uses the last good values from the ring buffer, so the music slows down yes, but at least it does not crackle. The corollary to this is that calling tic_core_tick_end(tic) is not enough during the Studio sound export; one should also call tic_core_synthesize_sound which does the job of pulling the sound registers from the tail of the ring buffer and doing the sound synthesis. The ring buffer is kept short on purpose, because if there slight desync between the TIC() frequency and sound frequency, the TIC() frequency might run faster and delay might build up. So, the ring buffer length sets a maximum on the delay that this technique can create.
Previously, the sound registers were used to synthesize fixed amount of sound after every TIC() and this was pushed to SDL. The problem with this approach was crackling if TIC() takes too long to reach 60Hz. In this fix, the sound registers are instead pushed to a ring buffer and the audio is synthesize in SDL callback to render audio. If the ring buffer does not have enough values, the sound synthesis uses the last good values from the ring buffer, so the music slows down yes, but at least it does not crackle. The corollary to this is that calling tic_core_tick_end(tic) is not enough during the Studio sound export; one should also call tic_core_synthesize_sound which does the job of pulling the sound registers from the tail of the ring buffer and doing the sound synthesis. The ring buffer is kept short on purpose, because if there slight desync between the TIC() frequency and sound frequency, the TIC() frequency might run faster and delay might build up. So, the ring buffer length sets a maximum on the delay that this technique can create.
|
The fork @vsariola wrote seems to fix all the problems I reported here. The audio doesn't (perceptibly) de-sync at any point - no matter how long tic80 is open - and I could uninstall pulseaudio. Thank you! |
Previously, the sound registers were used to synthesize fixed amount of sound after every TIC() and this was pushed to SDL. The problem with this approach was crackling if TIC() takes too long to reach 60Hz. In this fix, the sound registers are instead pushed to a ring buffer and the audio is synthesized in SDL callback to render audio. If the ring buffer does not have enough values, the sound synthesis uses the last good values from the ring buffer, so the music slows down yes, but at least it does not crackle. The corollary to this is that calling tic_core_tick_end(tic) is not enough during the Studio sound export; one should also call tic_core_synthesize_sound which does the job of pulling the sound registers from the tail of the ring buffer and doing the sound synthesis. The ring buffer is kept short on purpose, because if there slight desync between the TIC() frequency and sound frequency, the TIC() frequency might run faster and delay might build up. So, the ring buffer length sets a maximum on the delay that this technique can create.
Previously, the sound registers were used to synthesize fixed amount of sound after every TIC() and this was pushed to SDL. The problem with this approach was crackling if TIC() takes too long to reach 60Hz. In this fix, the sound registers are instead pushed to a ring buffer and the audio is synthesized in SDL callback to render audio. If the ring buffer does not have enough values, the sound synthesis uses the last good values from the ring buffer, so the music slows down yes, but at least it does not crackle. The corollary to this is that calling tic_core_tick_end(tic) is not enough during the Studio sound export; one should also call tic_core_synthesize_sound which does the job of pulling the sound registers from the tail of the ring buffer and doing the sound synthesis. The ring buffer is kept short on purpose, because if there slight desync between the TIC() frequency and sound frequency, the TIC() frequency might run faster and delay might build up. So, the ring buffer length sets a maximum on the delay that this technique can create.
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.
The text was updated successfully, but these errors were encountered: