Print

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

[Ilja]

Hello everyone.

I have a trouble.
I enable option "play file from memory..". But preloading is strange  
When I load album from SSD - preload is about 10 second (for ~800mb), but its start playing at once, before loading to RAM completely ends.
So this 10 seconds I hear "click... click.. click".
Question is: Like that was conceived by developers or still there are some settings that I could not find ?

I think must be status indicator of song loading to RAM. And after it loads - automatic playing.
Like in Aplayer, for example. It plays song only after loading to RAM, and no "clicks".

And second No Good: when I push "stop" button - it unload song from memory, and then after "play" pushing I must wait loading and hear "clicks" again.
After pause - NO unload.

PS When I load song from NAS HDD via RJ-45 I hear this clicks about 30 second..  

[JimH]

The clicks may be coming from your sound device.  You should not hear anything.

What are your audio settings?  Try others.

[6233638]

This is due to the Memory Playback changes introduced in MC19 which can cause spikes of CPU usage when the feature is enabled.
 
If your CPU is not powerful enough, you have other programs running on the system at the same time as MC, or if your playback device is one which is more susceptible to interruption from high CPU usage, there's little that can be done.
 
They don't plan on fixing it. You will have to disable the feature. (as I have had to)
I wish they would though. Memory Playback was a very useful feature before this change.
 
Now playback is either susceptible to interruption from high CPU usage (Memory Playback enabled) or from slow disk access. (Memory Playback disabled)
Memory Playback in MC18 largely avoided both these issues.

[kstuart]

It would be nice to have a "do not play files until loaded into memory" optional checkbox.

[Ilja]

The clicks may be coming from your sound device.  You should not hear anything.

In mode "playing from memory" after push "Play" button each two-three seconds the sound appears on half a second and vanishes. That I call "clicking". After load completes - all OK.
It is not a sound device defect, it is jriver output, because of much CPU resources are used for a loading from HDD to RAM

In best way it must be corrected..  

If your CPU is not powerful enough, you have other programs running on the system at the same time..

My CPU is powerful enough And is optimized for audio playing in software (system) and in hardware ways.

They don't plan on fixing it.

It is not difficult to fix it. Everything works OK, just need to start playing after track is loaded to RAM.
I think it can be solved by several program lines. Something like
"if (song is loaded =1)
push play
else
load the song further"
 

I wish they would though. Memory Playback was a very useful feature before this change.

Yes, of course. Playing from RAM is veeery useful function. Less jitter, less latency.. And with playing from RAM - I can use less buffers in JRiver.
All TRUE players like BugHead, Aplayer .. Plays only from RAM

It would be nice to have a "do not play files until loaded into memory" optional checkbox.

It would be nice to fix that. Or delete this function at all. Because the present but not working function in the commercial project it isn't good  


May be some people can transfer this request and opinions to JRiver developers  

[rs55]

WASAPI is now missing from Audio options.

[6233638]

It would be nice to have a "do not play files until loaded into memory" optional checkbox.

It is not difficult to fix it. Everything works OK, just need to start playing after track is loaded to RAM.

That would not fix this.
First of all, MC would have to switch to 64-bit and you would need to assign it at least 8GB of RAM all to itself to ensure that it can fully cache an entire track in the current system.
Secondly, that means you cannot do gapless playback, and potentially have gaps of 30+ seconds between tracks - because if you start loading the next track during playback of the current one, you'll get that same interruption in playback.
 
No, returning to the "old" Memory Playback system where the file is cached, and audio is decoded to a small ~30MB buffer would largely solve most of the issues that the "new" Memory Playback system has caused.
And expanding the old system, allowing MC to use up to (or more than) 1GB to cache multiple files at once rather than a single file would fix the only real issue that was present with the old system: being susceptible to slow disk access when changing tracks - though at least it was not susceptible to slow disk access during playback, as it is now.
 
The new system just eats up CPU and Memory resources for no benefit other than a marketing point, at the expense of performance and quality.
The only positive is that it can now cache SACD tracks while the old system could not - because SACDs are big files and MC is limited to 1GB.
But the benefit of that is lost when you cannot actually play SACD tracks without problems caused by the high CPU usage.


CPU usage and I/O from MC20 playing three tracks:


CPU usage and I/O from MC18 playing the same three tracks:

 
It's those big spikes in CPU usage and I/O that cause problems for playback.
MC18's constant but low-level CPU usage is error-free, and there is zero I/O during playback since it caches files rather than decoded audio. Overall memory usage is lower too.
MC20's behavior with Memory Playback disabled is similar to MC18's Memory Playback, only there's constant I/O during playback which makes it susceptible to interruption. (which does occasionally happen, since I actually use my PC instead of dedicating a system to music)
 
A revamped Memory Playback system which returns to the MC18 style of playback and expands upon it, is probably the #1 change I'd like to see for MC21.

[Ilja]

That would not fix this.
First of all, MC would have to switch to 64-bit and you would need to assign it at least 8GB of RAM all to itself to ensure that it can fully cache an entire track in the current system.

I am not expert in this questions, but I see what I see: Aplayer and BugHead on my system plays from RAM without any troubles.
From that I can do a conclusion -  it is not problem to do it without any 64-bit, 8 GB of RAM and something else.
I am right ? Yes, I am right.
How do that ? Its for JRiver developers. If they want - they can ask to developers of Aplayer, and BugHead. Buy technology or crack it.

Something about playing from RAM on other players:
When I load SONG (~40mb) to Aplayer it starts to play from the beggining (without clicking and problem), when I load album or big flac (~300-900MB) it starts playing only after this ALL album is loaded to memory. I can see process how memory is filled in task manager or ProcessLasso.
The amount of busy memory exceeds the real size of files approximately for 30%.

Secondly, that means you cannot do gapless playback, and potentially have gaps of 30+ seconds between tracks - because if you start loading the next track during playback of the current one, you'll get that same interruption in playback.

Gapless works OK on Aplayer, and BugHead, so I do conclusion - no problems do to that


So, I use JRiver only because of two reasons:
1) I can use it with Dirac room correction (it does not work with aplayer, and bughead)
2) I like to use remote control, Gizmo on Android. (Aplayer and bughead does not have remote control jet)

But sound from JRiver is worse that on BugHead, Aplayer.. And now I am doing some settings to improve sounding.
Helps decreasing of buffers, and turning off any function that does not belongs to audio.
But with playing from RAM - is trouble
Hope JRiver developers will resolve that problem soon.

PS
Plays through Berkeley Alpha USB -> NAIM DAC.

[6233638]

I am not expert in this questions, but I see what I see: Aplayer and BugHead on my system plays from RAM without any troubles.

Most players store the files in memory. And Media Center used to do this up to and including MC18.
In MC19 they decided to decode the track and store uncompressed audio data in memory, instead of the compressed file.
 
This is why the CPU and Memory requirements are greatly increased, and why playback is actually having to clear the buffer and decode another 1GB chunk of audio in the middle of a track if something decodes to >1GB. (typically large gapless FLAC files or DSD)
The high CPU requirements for trying to decode an entire 1GB chunk of audio as quickly as possible is why MC can actually interrupt its own playback.
Or why playback can pause in the middle of a track if the disk is busy.
And if it's not interrupting its own playback, the high CPU usage can interfere with other processes running on the system.
 
I would much prefer to have an option which stores files in memory instead of decoded audio, and use the additional RAM freed up by doing this to store as many files as it can possibly fit into 1GB, so that files are cached in RAM far in advance of playback, instead of in the last 10-20 seconds of the current track.

[JimH]

But with playing from RAM - is trouble

Don't play from RAM if it doesn't work, at least until you solve your other problems.

[Ilja]

So, I resolve problem in that way: I copy music from NAS HDD to Notebook SSD (SSD is much faster).
Divide to separate tracks and convert it to .wav (I use xrecode2, cause of cuetools does nos support 24/192).
Load .wav tracks to JRiver and play it from memory

Notes:
If I try to play from NAS HDD (maximum download speed through RJ45 is ~11mb/sec), so I need some 20 second to load for example 200mb track (24bit/192khz). And this 20 second I hear some defects in sound. For flac about 1gb - it will be longer

Now 200MB .wav track 24bit/192khz is loaded to RAM in about 1-1.5 seconds, and no defects in sound when loading.

It can be solved like that, but for not extreme CPU, and NAS HDD must be done delay of playing while track is loading to RAM.

[6233638]

So, I resolve problem in that way: I copy music from NAS HDD to Notebook SSD (SSD is much faster).
Divide to separate tracks and convert it to .wav (I use xrecode2, cause of cuetools does nos support 24/192).
Load .wav tracks to JRiver and play it from memory

Notes:
If I try to play from NAS HDD (maximum download speed through RJ45 is ~11mb/sec), so I need some 20 second to load for example 200mb track (24bit/192khz). And this 20 second I hear some defects in sound. For flac about 1gb - it will be longer
Now 200MB .wav track 24bit/192khz is loaded to RAM in about 1-1.5 seconds, and no defects in sound when loading.

It can be solved like that, but for not extreme CPU, and NAS HDD must be done delay of playing while track is loading to RAM.

This works around the problem because WAV files are uncompressed, so you have moved the decoding stage to an offline conversion process instead of MC trying to decode the audio during playback.
This can also inflate the file size by a huge amount. With FLAC files, expect them to double in size.
With DSD, it is hilariously inefficient. A single 5GB SACD becomes a 34GB collection of WAV tracks.
 
Which is a good illustration of the underlying problems with the "new" Memory Playback system.
With the old system you would need 5GB to cache the entire album in RAM. With the new system, that requirement increases to 34GB.
Now if you wanted to limit the cache to 1GB in size because MC is currently only a 32-bit application, well you could cache at least three or four tracks if you're caching the files.
The current system cannot fit even a single track into memory, and has to decode several gigabytes of audio during playback - each time having the potential for glitching/interruption.