Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Matias]

I have a SACD ISO running on JRiver latest version and I notice a lot of lag when changing between tracks using my HTPC. I opened up the Task Manager and saw that the JRiver executable is increasing its RAM usage up to 1.1GB, which I assume is loading the ISO file into memory (I have memory playback enabled). All OK until now.

The problem is when the track ends or if I switch to a different track within the same SACD ISO. The executable reduces RAM usage to 120MB and slowly starts increasing back to 1.1GB, meanwhile CPU running a lot. I assume it dumped the file from RAM and is reloading it, even though it is the same file. I haven't tested but I assume this would also happen with any other big file + cue (say flac+cue, wav+cue, ape+cue etc), it would reload the same big file for every track change?

Anyway this doesn't look like an optimized use of resources. Can't you create a check "if the next track uses same file then do not reload it into RAM"?

Thanks.

[6233638]

Memory playback stores decoded audio in RAM.
So it's storing the decoded track into memory, not the ISO file.

The maximum size for this buffer is ~1GB which is why you see it empty out and fill up again as the track changes.


I agree that memory playback could improved though, and there are some changes I'd like to see.

[Matias]

Decoding it to RAM explains the high CPU usage. But doesn't change the fact that it is doing it for nothing since it was already done before.

Really have to wait for 20? I was thinking of a single line of code with the IF clause...

Maybe remove the 1Gb restriction with an advanced flag? I see people building dedicated audio PCs with 16GB of RAM... Not my case, but loading all my 4GB RAM wouldn't matter to me.

[6233638]

Decoded DSD audio is huge.
It is not reloading the same data when you see this happen, it is loading the next track.
 
With a long track you will even find that this happens during playback, as the whole track cannot fit into the ~1GB buffer.

Media Center is a 32-bit application, which I think is the reason behind the 1GB limit.
I agree that the current situation is not ideal: http://yabb.jriver.com/interact/index.php?topic=89630.msg615558#msg615558

For slower systems, it would actually be better to disable memory playback now.

[Matias]

Agreed, I just disabled the feature until it is improved. The lag is so much for SACD that it may even skip (AMD E350 APU here), using large buffers and all.

[JimH]

Media Center is a 32-bit application, which I think is the reason behind the 1GB limit.

That's not correct.

[6233638]

That's not correct.

Well I know that 32-bit applications allow for 3-4GB to be used, depending on the OS, but I thought that was part of the reasoning behind it.

If not, could we see that expanded in MC19? 1GB is not enough to store some tracks completely in memory.

As above, I'd like to see some larger changes to memory playback overall, but I wouldn't expect them in this version.

[dean70]

Maybe a CPU throttle setting needs to be added. I also experience slight stuttering during hires track changes using W4S ASIO driver (does not occur using Kernel Streaming driver). This is with the lastest and greatest H97 chipset, i54590s, etc.

[6233638]

Throttling the amount of CPU Media Center uses for audio playback would be nice.

The old method of playback where it was only trying to fill a small ~30MB buffer quickly, rather than ~1GB was a lot easier on the CPU, though there was still a large spike of CPU usage at the start of the  track - it just didn't hit 100% on my system.

In MC19 with or without memory playback, there's a big spike of 100% CPU usage that can, ironically, interfere with playback causing it to skip at the start/end of a track.

I find that it really interferes with other applications running on the system too.
Since the upgrade to MC19, I cannot play SACDs in the background when playing a game for example, as it causes it to stutter every few minutes.
 
 
I'd much rather return to the small ~30MB buffer of decoded audio - maybe even smaller than that.
I'd then like to cache the files in RAM. Either the whole ISO where possible, or if I'm playing another format like FLAC, something like the current track and the next two tracks.

Other than caching SACD ISOs, it would use less memory overall, reduce CPU usage, and make Media Center immune to disk access again. (as long as it can cache the next track in the next 6+ minutes rather than the ~20 seconds it has now)


Rather than Memory Playback On/Off, I'd like to see separate options for the Playback Buffer (decoded audio) and File Cache. That way people can choose for themselves whether they want to store the entire track as decoded audio in RAM or load the files into RAM and decode during playback.