More > JRiver Media Center 19 for Windows
NEW: Improved memory playback
rayooo:
--- Quote from: 6233638 on August 16, 2013, 06:44:00 am ---Is no-one else having problems with the new memory playback—particularly with DSD?
I can’t use memory playback any more, because it has 100% CPU usage for ~20 seconds every time the track changes, and it makes seeking slower instead of being instant like MC18 because it has to buffer all the time.
It also uses 2–4x the RAM for no benefit. It's a major issue.
Does everyone else just have a system dedicated solely to music playback and not actually use their PC for anything else at the same time?
--- End quote ---
I don't have DSD (yet) all PCM/WAV currently. My main player is dedicated to audio, desktop is multi purpose with SPDIF output to cheapo DAC. It's a multi use machine..but 16Gig RAM and way over powered for the need.
near as I can tell simply using Windows Resource Monitor... during track change, network usage goes from virtually zero up to approx 90Mbit/Sec and 10% utilization for a brief time. CPU usage goes from 1% up to approx 4%, again, very briefly.
Only other tasks going on are Email (Outlook) and Browser (Firefox)
I'll check this info again on the main player (dedicated listening room player) and see what it shows.
...PS I need to get a DSD Dac to play with.
JimH:
DSD files are very big. Loading from a slow drive or a network drive would be noticeable.
InflatableMouse:
--- Quote from: 6233638 on August 16, 2013, 06:44:00 am ---Is no-one else having problems with the new memory playback—particularly with DSD?
I can’t use memory playback any more, because it has 100% CPU usage for ~20 seconds every time the track changes, and it makes seeking slower instead of being instant like MC18 because it has to buffer all the time.
It also uses 2–4x the RAM for no benefit. It's a major issue.
Does everyone else just have a system dedicated solely to music playback and not actually use their PC for anything else at the same time?
--- End quote ---
I have one album in dff, SRV& DT, Couldn't stand the weather, so I figured I'd give it a swing. 2nd track loads 1,3GB in memory. It plays instantly and skipping is instant. I actually had to check memory playback was enabled because I expected at least some delay.
Edit: I'll recheck later, cpu is at 100% because analyze is running minimized. :-[
6233638:
--- Quote from: JimH on August 16, 2013, 07:35:36 am ---DSD files are very big. Loading from a slow drive or a network drive would be noticeable.
--- End quote ---
They're loading off a 4TB WDSE which is one of the faster hard drives around. (171MB/s)
The problem is that memory playback no longer caches the file it's playing in memory - it relies on disk/network access when decoded audio exceeds the 1GB buffer (common with DSD files) and DSD files require much more CPU than PCM to decode.
Because it's trying to fill 1GB of decoded audio as quickly as possible, you have maybe 20 seconds of 100% CPU usage (on a fast system - 5000 JRmark score) every time there's a track change or seeking occurs, and there's maybe 5-10s of silence as it buffers.
If I'm doing anything else on the computer, this prolonged CPU usage every time there's a track change interferes with whatever else I was using the system for.
In MC18 which cached the files in memory and used a ~40MB buffer, seeking was instant, CPU usage was about 20% at most (typically <1%) and I never had Media Center tell me that it was "buffering" during playback.
The largest single track I have is ~500MB (20 minute multichannel DSD file) which meant that MC18 had half the memory footprint of MC19. (typically much lower)
This seems like a serious regression in performance and usability just to tick off an audiophile checkbox.
The seeking issues would be solved if Media Center had a larger buffer that allowed the entire file to be decoded into memory (which probably requires a 64-bit build and more than the 8GB RAM I have) but that would then make the high CPU and memory usage even worse. As I understood it, JRiver's position was that memory playback should not have any impact on audio quality, so that seems like it would be heading in the wrong direction.
The best solution seems like it would be to make the size of the decoded audio buffer adjustable (so I can reduce it back down to ~40MB or whatever MC18 used, rather than 1GB) and to bring back the option of caching the file so that disk/network access is not a factor. The logical extension of that seemed like it would be to allow caching multiple files at once—even just two—so that disk access can never impact playback. (currently Media Center only starts loading the next file in the last ~10s of a track) Even with two tracks cached (the current and next one) memory usage would be lower than it is now.
--- Quote from: rayooo on August 16, 2013, 07:12:05 am ---PS I need to get a DSD Dac to play with.
--- End quote ---
I'm actually converting to PCM to take advantage of Volume Leveling.
mojave:
--- Quote from: 6233638 on August 16, 2013, 09:03:07 am ---Because it's trying to fill 1GB of decoded audio as quickly as possible, you have maybe 20 seconds of 100% CPU usage (on a fast system - 5000 JRmark score) every time there's a track change or seeking occurs, and there's maybe 5-10s of silence as it buffers.
--- End quote ---
I have 312 dsf files on an external USB hard drive. With memory playback, the files play instantly, seeking is instant, and changes to the next track are instantaneous. I have a 32-bit Windows 7 computer (3707 JMarks) with 3 GB of memory. JRiver only uses about ~600 MB even if I'm showing 2 Gb available. My CPU goes to 14% for two seconds before dropping back to 0, but playback is instantaneous.
I played my largest track (720 MB) and smallest track (77 MB) with no problems.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version