Add some sources

Audio-specifics.md

@@ -6,7 +6,7 @@ The human ear can generally pick up sounds ranging from 20 Hz to 20,000 Hz, alth
 
 Every sample uses a number of bits, for example CD audio uses 16 bits per sample. Combined with the sampling rate of 44,100 Hz, and multiplying by 2 for the amount of channels, this gives out 1,411,200 bits per second, or 176,400 bytes per second. (Which gives us 747 MiB for a 74-minute CD.)
 
-When playing digital audio on a computer, the samples have to be loaded into a buffer. When the buffer runs dry, the result is often a crackling sound. This can be mitigated by making the buffer larger, but that does mean increased latency. The latency can be calculated by taking the amount of samples in the buffer, dividing them by the sample rate and multiplying by 1000 to get the number in milliseconds. For example, a buffer of 2048 samples playing at an output rate of 22,050 Hz (which is what OpenRCT2 does as of November 2025) means a latency of 93 ms.
+When playing digital audio on a computer, the samples have to be loaded into a buffer. When the buffer runs dry, the result is often a crackling sound. This can be mitigated by making the buffer larger, but that does mean increased latency. The latency can be calculated by taking the amount of samples in the buffer, dividing them by the sample rate and multiplying by 1000 to get the number in milliseconds. For example, a buffer of 2048 samples playing at an output rate of 22,050 Hz (which is what [OpenRCT2 does as of November 2025](https://github.com/OpenRCT2/OpenRCT2/blob/develop/src/openrct2-ui/audio/AudioMixer.cpp#L30-L33)) means a latency of 93 ms.
 
 When the sampling frequency of the audio file does not match the output frequency, or the amount of channels, or the bitrate, the file has to be resampled. When combining this with streaming the audio off the disk, like RCT2 and OpenRCT2 do, special consideration has to be given to make sure enough data is read to fill the buffer at the output frequency. 
 
@@ -18,4 +18,7 @@ OpenRCT2 currently uses SDL2 and has to output everything at the same output fre
 
 With the resampling bug fixed, it _may_ be safe for OpenRCT2 to raise the output frequency without running into crackling issues. However, this will need careful testing. A higher output frequency also means that more data has to be moved at any given time, and if the game cannot fill the buffer quickly enough, crackling will still occur. Besides the output frequency, the number of samples in the buffer also needs consideration. Generally, you want to increase the number of samples in the buffer more or less linearly with an increase in sampling rate, as doubling the output frequency obviously means the buffer is essentially halved. Doubling both of them keeps the latency the same.
 
-SDL3’s audio system is more flexible around differing sample rates. In SDL2’s setup, you open an audio device with a set output frequency, bitrate and number of channels, and any audio sent to the device has to adhere to these parameters. In SDL3, you can set these per stream, meaning that SDL handles any conversions needed. (A similar setup may be possible in SDL2 by using SDL2_mixer, though this has not been fully investigated.)
+SDL3’s audio system is more flexible around differing sample rates. In SDL2’s setup, you open an audio device with a set output frequency, bitrate and number of channels, and any audio sent to the device has to adhere to these parameters. In SDL3, you can set these per stream, meaning that SDL handles any conversions needed. (A similar setup may be possible in SDL2 by using SDL2_mixer, though this has not been fully investigated.)
+
+## Unsorted sources
+- https://github.com/OpenRCT2/OpenRCT2/commit/3348ad1430ddcbde6176a88b65be22a1d2d6bdb7