You've got a real ax to grind. That's just not true.
It is absolutely true, and I have repeatedly posted evidence of this.
Enabling Memory Playback in MC18 had little-to-no effect on CPU usage, and made playback far less susceptible to interruption, since the file was stored in RAM.
In MC19 enabling Memory Playback can introduce significant CPU activity every time that the buffer is refilled, and many tracks are now only partially stored in memory since, uncompressed, they do not fit into the 1GB buffer.
This makes playback highly susceptible to interruption in the middle of a track due to slow disk/network access, or high CPU activity.
There are even users who have experienced playback interruption
caused by the increased CPU usage that the Memory Playback changes in MC19 introduced, and the only solution for them has been to disable it.
In MC18 playback could only be interrupted by slow disk/network access when changing tracks, never in the middle of playback.
The changes to Memory Playback that I have proposed would not only restore MC18's robustness during playback, but make it even less susceptible to slow I/O by caching more than just the currently playing track.
Rather than only allowing ~20 seconds to cache the next track, caching the current track and the next two (or perhaps the current track and as many tracks fill ~10 minutes of audio) should leave more than enough time to almost eliminate the possibility of slow I/O interrupting playback.
In most cases this should use less RAM than the current system as well, since it would be caching files rather than decompressed audio.
Since the changes made in MC19, I have been unable to leave Memory Playback enabled:
1. For the first four months, SACD playback would drop a portion of the audio when the buffer was refilled.
2. Because I cannot run anything else on my computer without the increased CPU usage interfering.
It interferes with basic tasks such as scrolling a webpage, and makes it impossible to run demanding tasks without causing interference.
With demanding tracks such as multichannel SACD playback, things can get so bad that it even manages to interfere with the
mouse cursor.
Reverting to MC18, or limiting Media Center to a single CPU core prevents this from happening—so it isn't that my PC can't handle multichannel playback, it's that the way MC handles it causes problems.
Since the official JRiver stance on Memory Playback is that it does not affect sound quality—which is something that I agree with—it should be designed to make playback as robust as possible.
On a high-end development machine where testing may be done with fast disk/network access with MC being the only task running, perhaps the new Memory Playback system appears to be working well.
But on slower systems, or times when other applications are tying up the disk/network (even things like Analyzing Audio in MC while playing music can do it) it is better to disable Memory Playback rather than leaving it enabled.
Memory Playback should be increasing the robustness of playback at the cost of using more RAM.
Right now it just eats a gig of RAM for no apparent reason.