More > JRiver Media Center 23 for Windows
Loading to memory setting
dtc:
Some people believe that the disc activity during playback can affect the sound although most cannot hear any difference. It is definitely system dependent.
It can also be used to insure that there are no hiccups when using a usb or network drive or a NAS, especially for high resolution files and for slow systems.
dtc:
The reason there are two options is that a large decoded file may not fit in the amount of memory available and the mid track reload can cause glitches. Hence the option to load the compressed file. Once again this is an issue with high rez files.
RD James:
--- Quote from: Awesome Donkey on July 15, 2017, 05:17:24 am ---IMO, it all sounds the same to me.
I guess try them and see for yourself.
--- End quote ---
It's not about sounding different, it's about preventing stalls when seeking or loading tracks off a slow disk/network connection.
If they sounded different, something would be broken!
They never did expand it to buffering albums/playlists in v22 as planned though, so the feature doesn't really do a lot right now, unless you have severe disk or CPU access which would otherwise manage to interfere with the currently playing track.
--- Quote from: dtc on July 15, 2017, 06:18:18 pm ---The reason there are two options is that a large decoded file may not fit in the amount of memory available and the mid track reload can cause glitches. Hence the option to load the compressed file. Once again this is an issue with high rez files.
--- End quote ---
It also places different loads on the system.
Decoding a track into memory can put the CPU at 100% for a few seconds as tracks change, which can be very disruptive if you are doing more than just listening to music on your PC.
Storing a compressed track in memory keeps CPU usage low, but prevents disk access from interrupting the current track's playback.
DomieMic65:
Very interesting information guys ...
@RD James : why are you talking about compressed track in the above reply?
May be you meant "decoded"?
RD James:
--- Quote from: DomieMic65 on July 16, 2017, 03:50:21 am ---Very interesting information guys ...
@RD James : why are you talking about compressed track in the above reply?
May be you meant "decoded"?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version