Use a separate thread to update the display (#57)

[drfiemost]

No description provided.

[ruby-R53]

not sure if you're aware but it seems like the display doesn't get updated enough here, it gets quite noticeable with tunes that switch waveforms very fast like Jeroen Tel's Kinetix.sid at subtune 1

which's weird considering the display updates every 16 or 20 ms, to correspond to 60 and 50 Hz··· and lowering that refresh rate just makes the screen flicker more while still not updating the information properly

[drfiemost]

Yeah, it seems like updates happen in bursts, have no clue why...

[drfiemost]

Oh wait, the problem is that the audio writes are blocking so there is no update to the emulation while buffers are played back. So we are still limited by the buffer size. If you try with -w you can see the display is very quick.

[ruby-R53]

yeah that's what i was guessing x)

[ruby-R53]

hey, i decided to fiddle with this code on my fork and i got some promising results

i'm still limited by the buffer size as well but at least making a new thread for refreshing the display gave it a more consistent refresh rate, so i'm already somewhere (i'm still using the old approach for the buffer size because of that, it would look really janky with the current one)

apparently pa_simple_write() really blocks the execution program-wide, so making a thread isn't enough here, and now i'm trying to figure out if there's any way to circumvent this···

either that or we just drop PulseAudio support in favor of a better API that better communicates with this code i guess ¯\_(ツ)_/¯

EDIT: hmm just checked PulseAudio's Asynchronous API, maybe that could help as it's designed for threaded apps so here is a path we can take

[drfiemost]

Currently reworking the playback logic, not sure if this is still useful.
Anyway, all the audio backends are blocking, using async output would require some callback mechanism.

[ruby-R53]

yeah that's what i thought