In MC19, there were some big changes to the way that Memory Playback was handled.
In short, the program uses more memory and CPU power, yet playback is now a lot more sensitive to CPU usage and disk/network access than it was before.
This has caused playback to stutter for a number of users, and causes MC to interrupt other programs when the option is enabled.
SACD playback is worst affected, with massive CPU spikes occurring in the middle of playback—though SACD performance in general got worse in MC19.
Media Center 18:
Media Center 19 with Memory Playback Enabled:
Media Center 19 with Memory Playback Disabled:
Now I do not know the specifics of how this was changed in MC19, but it appears that there are two buffers that Media Center uses:
Once which caches the file, and one which caches decoded audio.
In MC18, the entire file was cached in memory, and the decoded audio buffer was maybe 30MB in size. (excluding SACD ISO, since the files are so large)
This meant that the current track could not be interrupted by slow disk/network access, and CPU usage was low.
In MC19, it seems that the file cache was eliminated, and the size of the decoded audio buffer was increased to 1GB.
This means that the track can be affected by slow disk/network access if it doesnʼt fit entirely in memory, and that there are large CPU spikes when it tries to quickly decode 1GB of data.
These CPU spikes are so high that they can actually interrupt playback, or interfere with other programs running on the system.
I can no longer listen to music via MC while playing games if Memory Playback is enabled, for example.
Having control over these two buffers would greatly improve things.
I would like to return to caching the entire file in memory, and only using a very small buffer for decoded audio.
That way it becomes far less sensitive to slow disk/network access, and Media Centerʼs CPU usage should remain low enough to prevent audio from stuttering, or interfering with other programs.
But Iʼm not asking for all these changes to be reverted—after all, they were implemented for a reason, and some people
will want to have a large cache of decoded audio—possibly even larger than 1GB, or maybe something less than 1GB, but not as small as before—say 256MB.
And I would like to see the file caching options expanded as well. Rather than only caching the current track, caching the current
and next track would greatly improve things, as it should give MC
minutes to cache the next track, rather than 15-20 seconds as it currently is.
It could even be that you specify a size such as 1GB—or perhaps a duration would be best—where MC would try to fit as many upcoming tracks as possible into RAM, within that limit.
Current plus the next two would probably be enough to ever prevent slow disk access affecting playback though, without increasing disk/network access to the point that it might affect other applications.
Current plus one may not be sufficient, as some albums have 15-30 second “intermissions” between certain tracks.
Author
Topic: CPU Usage and Mouse Problems (Read 18639 times)