Make PulseAudio return accurate latency information

[EIREXE]

This seems to be the most reasonable approach, the old approach gave wildly different values per startup, see the stepmania source code for reference I used, they don't seem to do any latency compensation at all, but I tested with a latency testing tool and the approach I used seems to be the correct one:
https://github.com/stepmania/stepmania/blob/984dc8668f1fedacf553f279a828acdebffc5625/src/arch/Sound/RageSoundDriver_PulseAudio.cpp#L178

[MJacred]

Hm… like @ellenhp said here #45152 (comment), it's better to get the latency during mixing

Don't forget: PulseAudio is quite particular about its latency, so using pa_stream_get_latency is kind of must:

If PA_STREAM_ADJUST_LATENCY is set, then the tlength/fragsize parameters of the pa_buffer_attr structure will be interpreted slightly differently than otherwise when passed to pa_stream_connect_record() and pa_stream_connect_playback(): the overall latency that is comprised of both the server side playback buffer length, the hardware playback buffer length and additional latencies will be adjusted in a way that it matches tlength resp. fragsize.
source: https://freedesktop.org/software/pulseaudio/doxygen/streams.html

IMO that PR is the better and more accurate approach

[EIREXE]

Hm… like @ellenhp said here #45152 (comment), it's better to get the latency during mixing

Don't forget: PulseAudio is quite particular about its latency, so using pa_stream_get_latency is kind of must:

If PA_STREAM_ADJUST_LATENCY is set, then the tlength/fragsize parameters of the pa_buffer_attr structure will be interpreted slightly differently than otherwise when passed to pa_stream_connect_record() and pa_stream_connect_playback(): the overall latency that is comprised of both the server side playback buffer length, the hardware playback buffer length and additional latencies will be adjusted in a way that it matches tlength resp. fragsize.
source: https://freedesktop.org/software/pulseaudio/doxygen/streams.html

IMO that PR is the better and more accurate approach

Yeah this PR isn't very good, I suggest anyone making a rhythm game in godot to use a custom audio solution, like shinobu