I thought there was another option that allows loading the entire album in the memory. Wouldn't that work for this?
Unfortunately not. The short version is that the description is literal. It will load the entire Playing Now list (not just an album) into memory before playback begins.
Originally there were very few limitations on this, so you could be waiting
several minutes while it filled up 16GB of RAM before playback would begin.
Since it is only storing non-decoded tracks, it still does nothing to protect against high CPU usage from other processes interrupting playback.
I believe the memory limit for this feature has been reduced, but the problem with that is if the tracks in Playing Now exceed that amount, you wait minutes for it to
try and fill up all of your RAM, have it fail, and then without any warning it will play directly from the disk/network as though you never enabled it to begin with.
It's not dynamic at all either. It doesn't try to keep an "album's worth of tracks" (say 10 tracks) in memory.
If you start playback when there are only 10 tracks in Playing Now, and add more to it, it does not try to load more upcoming tracks into memory when the current track finishes. It will reach the end of those 10 tracks and fall back to loading individual tracks into memory at the end of every track.
The only thing that option does is prevent slow disk/network access from interrupting gapless playback, and does it in the least efficient way possible, by eating up all of your free RAM.
"Load full file (not decoded)" is an efficient way to do memory playback, as it only stores one track in memory at a time, but it only protects against slow disk/network access for the current track.
High CPU usage can still interrupt it, and slow disk/network access can still create gaps during playback as it only has the pre-buffering duration to load the next track into memory - and that's often not enough.
"Load decoded file into memory" uses more RAM (a
lot more for formats like DSD - particularly multichannel) but can protect against both slow disk/network access during playback,
and high CPU usage during playback - to a point.
The issue is that this option
creates very high CPU usage at the end of every track because it tries to decode the next track as quickly as possible.
This means it doesn't play nicely if you use your computer for anything else. For example: if you are playing a game and listening to music, it can cause bad stuttering every time the track changes.
Ideally the playback system would be some combination of these options:
- It would store tracks non-decoded in memory, since that uses significantly less RAM.
- It would store multiple tracks in memory to prevent slow disk/network access causing gaps in playback; ideally this would be a buffer of a minimum audio duration rather than a fixed number of tracks (keep 10 minutes of upcoming audio in memory) or perhaps a fixed size (keep a buffer of 1GB) since a fixed number of tracks could vary significantly in duration/size.
- It would unload previous tracks, and load tracks in advance. It should never be loading the next track into memory in the last few seconds of the current track. At the very least, the next track should always have been loaded into memory before the current track started playing.
- Optionally, slowly decoding the upcoming track into memory could help prevent issues on systems where the cause of interruptions is high CPU usage from other processes. Decode the first track into memory quickly, but then use a rate-limited decoding for the next upcoming track or two, to prevent large spikes in CPU usage. This option would have moderate memory and CPU usage, but protect against all scenarios where playback could be interrupted, rather than only some of them.
You can
kind-of force Media Center to buffer the upcoming track early if you edit the registry to extend the pre-buffering duration to something far longer than 20 seconds.
If I recall correctly, I set it to ~180 seconds the last time I tried this, which meant that it loaded the current track in memory and had plenty of time to load the upcoming track as well.
The problem is that once Media Center enters the pre-buffering stage of playback you lose control over the currently playing track, and the option would reset after restarting Media Center.
Currently, the only option that I would recommend people use is the "Load full file (non-decoded) into memory" one, as it does not use an excessive amount of RAM, and prevents disk access interfering with the currently playing track.
However, this can break gapless playback if you are loading from a network connection or a portable disk that sleeps frequently.
This scenario, where the issue is high CPU usage from other processes running on the system interrupting playback, is the only time I'd recommend the "Load decoded file into memory" option.
It's why I'd like to see Memory Playback revamped for MC25. Most of the components for creating an ideal Memory Playback system are there, but it needs reworked to create a system that prevents most if not all causes of playback interruption, without also causing Media Center to interfere with other processes running on that computer - whether that's excessive memory usage, disk access, or high CPU usage.
Author
Topic: Prevent sound breaks during 100% CPU load (Read 1980 times)