While the song is playing, it is beneficial to sound quality to reduce other system activity that would normally occur: reading song bytes from storage or network.

The best way to do this is to preload the complete song to RAM before playing. Euphony tries to do that whenever possible, but the exact functionality and extent of buffering depend on several factors:

• song location - local (disk or network) or online (Tidal, Qobuz) 
• output location - local DAC or UPnP endpoint
• player in use - Stylus, StylusEP, Roon, RoonBridge, Squeezelite, HQPe

I will try to cover all combinations and explain what exactly happens in each case.

Stylus

Stylus player will preload local songs to RAM before playing only if the 'Buffer before play = 100%' option is enabled.

Online songs will always be buffered to RAM (regardless of 100% buffer option) but if a new song is added to the queue and the play starts immediately, then the buffering will happen during playback. Buffering happens at max network speed so this network activity will go in parallel to playback for at least 5-10 seconds of playback - depending on your network speed, song quality and song length.

However, if you just add the song to the queue and you wait until it is downloaded in full and only then you start the playback, the song will play with no additional network activity - it will be fully played from RAM from the start to end.

This is also valid for the next song if you add at least two songs. Second song will be also downloaded in the background at the same time so if you add at least 2 songs to the queue from online sources you will have to wait until both are fully buffered to have a chance at 'clean' 100% buffered playback.

Note that if you add more than 2 songs to queue and you wait until the first two are fully buffered before playback at the moment when the first finishes and the second starts playing the download of the third song will start in the background and you will not have a clean playback of the second or any of the following songs in the queue except the last one.

Stylus also has 'Buffer albums added to queue' setting and 'Buffer queue' command. This setting only influences local songs. 

These will both do the same thing - buffer all songs present in the queue to RAM. However, if you add the album with Add & Play, the playback of the first song will start without waiting for the entire album to be buffered so your first song will not play cleanly (but all others will). Of course, it is possible that the whole queue or the whole album added to the queue will not fit in available free RAM. In that case, buffering will stop when there is not enough space. Songs that were not buffered will be buffered when they are next to play (remember that Stylus always buffers current and the next song).

While it would be easy to implement the buffering of the whole online album, we are just not allowed to do that with the API we are using.

Stylus + HQPlayer

When HQPe is enabled in Stylus and the source is Qobuz or TIDAL the file will be downloaded fully to RAM before actual playback. Local files are buffered according to the same rules as with only Stylus playback.

Stylus to UPnP endpoint

When Stylus output device is UPnP Renderer endpoint Euphony will fully buffer an online song before offering playback URL to the UPnP Renderer. Playback URL offered is local URL pointing to the song location in RAM drive, This means there is still network traffic between Euphony and Renderer but there is no other internet traffic during UPnP playback, Stylus always serves local URLs because some UPnP renderers require special UPnP-specific header fields that online music services don't provide so playback fails (and there is no way to detect if Renderer will play an URL until this is actually tried.)

Stylus and 'Use cache' option

Option 'Use cache' is a convenience option which will make a copy of any song added to the queue from external resources (mounted USB drives or network shares) and put it in a special /data/Music/E_CACHE folder. Next time you need those songs, they will be accessed from that cache. This can help in several ways:

• Songs that you listen to often will be available even if your external storage is not attached or your network share not connected.
• Songs will load faster (if your Euphony installation drive is fast) and there will be much less USB or network traffic. If buffering options are not enabled this can also improve sound quality.
• If used with '100% buffer' and 'Buffer albums added to queue', where you want an ideal situation: to listen to the whole album from RAM with absolutely zero unnecessary background activity or network traffic - then your waiting time for the whole album to be buffered is much shortened! And even in situations when the whole album cannot fit in RAM, buffering at the moment of playback of the songs that did not fit will go from cache and will be much faster and have a  minimum impact on listening experience.

To clarify the last point: while album buffering will stop when there is no space left in RAM (rest of the songs will not be buffered), buffering of individual songs at the time of playback will expunge already played buffered songs from RAM to make space for the current one.

On the same note - once the cache is filled (there is no more space on Euphony /data partition) 'oldest' songs (those that were first added to cache) will be removed in order to make space for new ones.

Roon 

We don't know that much about Roon's internal workings, but we know that Roon will never serve an online URL directly to its endpoint (whichever endpoint is in use). Roon maintains a http server on which it serves the URL of its music stream. This stream can contain one song (endpoint will get another URL for the next song when first finishes) or it can contain many songs which are all served on the same URL as one continuous stream (much like ordinary online radio streams). It does not matter if the original song is a local song or an online song - Roon behaves in the same way,

All this points to some kind of preloading happening on the Roon side, but from what we could gather while testing our StylusEP endpoint as Roon endpoint, and from monitoring network activity, we concluded that Roon does not preload the whole song. It has some memory buffer, but it does not encompass the complete song to be played. This severely limits our options for buffering on the endpoint side, but we cannot do anything about it. 

StylusEP as Roon endpoint

StylusEP can serve as an endpoint to Roon  (on the same machine or on the endpoint machine). Unfortunately, since Roon does not provide the whole song on its streaming URL, StylusEP can only buffer the amount of data available. As endpoint reports to Roon its playback position Roon decides when to provide more data based on that position (we did not investigate when this exactly happens, does it depend on percentages, on amount of data played or something else).

This all means that songs served from Roon cannot be played in full without intermediate network traffic somewhere during the playback time (probably happening multiple times). StylusEP will always try to read as much data as is available on Roon stream as fast as possible but there is no way to avoid network traffic during playback of a song.

StylusEP as Stylus endpoint

Stylus and SylusEP can be employed in two machine setup. When StylusEP plays a song served by Stylus then StylusEP will preload the whole song before playback. Stylus itself will respect 100% buffer and Buffer album added to queue flags itself and will keep songs in server RAM but StylusEP will pre-download those songs from Stylus server only one at a time, before playback.

Other players

Squeezelite or HQPe as Roon endpoints cannot do any better than StylusEP in terms of buffering - there will always be network traffic but for how long and in what intervals depend, in addition to Roon's buffering dynamic, to the buffer sizes in these applications.