Very interesting information guys ...
@RD James : why are you talking about compressed track in the above reply?
May be you meant "decoded"?
There are two options for memory playback:
1. Load full file (not decoded) into memory.
2. Load decoded file into memory.
The first stores the compressed track in memory and decodes during playback.
This uses a small amount of memory, keeps CPU usage low (but constant), and prevents disk/network activity interrupting playback for the current track.
The downside is that if you are playing a long track, the network connection or disk may go to sleep and you will have to wait for it to spin up again to load the next track, and a 20s pre-buffer may not be long enough.
That is why JRiver would ideally load multiple tracks into memory instead of only one.
The second option begins to decode the track into memory before it starts playing.
This can spike CPU usage to 100% 2-20 seconds before the current song finishes depending on the prebuffering setting, and uses a lot of memory.
If the decoded file is too large, it may have to do this in the middle of playback too, which makes it susceptible to slow disk/network access interrupting playback.
These spikes of high CPU usage can be disruptive if you are playing music in the background while using the computer for other tasks, and on some systems can even cause buffer underruns during playback.