Play file(s) from RAM

[simoncn]

Actually, the difference between "playing" and "streaming" is very significant in this context.

A renderer that plays audio can assemble the audio data in a memory buffer and control all implementation details of how audio is played from that buffer. For a server such as MinimServer, the output is a network stream that is subject to multiple levels of buffering and packetization by lower levels of networking code, controlled by TCP handshaking between the sending and receiving ends of the network connection. In parallel to this, the server needs to read audio data from disk (when playing a local file) or from the network (when playing an internet radio stream) and might also be doing other processing such as transcoding or convolution which can require routing the audio data through a separate FFmpeg process before it goes to the network output.

To cater for all these scenarios in the simplest and cleanest way (simplicity is usually beneficial for sound quality), MinimServer uses a multithreaded streaming architecture with different internal streaming connections to handle these different scenarios. For the most common scenario of streaming a local file, there is a reader thread for reading from disk and a writer thread for writing to the renderer via the network. These threads are connected by a circular ring of memory buffers, with the reader thread filling the next available buffer when it becomes empty and the writer thread emptying the next available buffer when it becomes full.

There are 5 buffers in this ring, each with a size of 16 KB. I have experimented with different buffer sizes and numbers of buffers and have found no benefit in increasing either the number of buffers or the buffer size. Because MinimServer can read data from the file more quickly that the renderer can accept it for playing, the buffer ring is always full and waiting for the renderer to accept the next buffer so that it can be refilled by the reader thread. The network connection can only send packets of about 1400 bytes each, so having a larger amount of data queued up in memory makes no difference to what happens when the data is written.