Print

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

[Blueline]

What does this mean

Memory such as Ram
Memory such as SSD (JRiver move files to an SSD disk before playing Music)

Can you clarify this

[JimH]

It means that the file(s) are loaded into RAM before playing them.  Some people think that minimizing disk access during playback improves the sound. 

[RD James]

I don't see how it would affect the sound quality at all.
The larger benefits of the proposed changes to v22 are that it will use your RAM more efficiently, can reduce power consumption (allow drives/network connections to sleep), and should eliminate pauses when skipping/seeking.
It will hopefully reduce CPU usage during playback compared to recent versions of JRiver too.

Of course this all depends on implementation. I'm looking forward to when this is in.

[Blueline]

It means that the file(s) are loaded into RAM before playing them.  Some people think that minimizing disk access during playback improves the sound. 

Perhaps useful for those playing via network or Local HDD, I use SSD to oprative system and SSD to Music Archive.
I guess I have no need for this.

[RD James]

RAM is still significantly faster than an SSD and sleeping the drive still matters if you're on a portable device.
I suspect that most people are storing their media on hard drives or NAS devices rather than locally-attached SSDs.

[kstuart]

I don't see how it would affect the sound quality at all.

There have been multiple double-blind studies of audio convention attendees that established that processes running during audio playback (such as decompression of compressed files) affect sound quality.

Those studies included two different PCs of different "power" (speed, memory, etc.) and the effect was less on the faster PC.  The resulting hypothesis was that the cause was electrical in nature.  PCs are not designed to be used in real-time and competitively priced parts often barely meet specs.

Please note that these differences are very small.  There are much greater differences between two remasterings of an album.

[JimH]

If you're going to cite studies, please also include a link or two.

[Krunchy]

Hello,

just a short question: is this feature only working with an album? Or can it work also with a selection? A playlist?
Thanks

[Blueline]

RAM is still significantly faster than an SSD and sleeping the drive still matters if you're on a portable device.
I suspect that most people are storing their media on hard drives or NAS devices rather than locally-attached SSDs.

SATA 2 port has better sound quality when compared to the SATA 3 port
speed is not always so good, it generates noise.

[BillT]

There have been multiple double-blind studies of audio convention attendees that established that processes running during audio playback (such as decompression of compressed files) affect sound quality.

Multiple; at least 2, OK.
double-blind; should be good.
studies; ah, academic even better.

of audio convention attendees; oh dear, it all falls apart now. You aren't at all likely to be able to do well controlled studies of any sort, let alone double blind ones, at an audio convention. At the very least, the conditions are inimical to sound quality assessment.

No references, which should be readily available if a proper study had been conducted; totally unconvincing.

[millst]

Yeah, I hate that when my computer has too many processes running and my Excel results come out slightly different.

-tm

[dtc]

Guys - this is not the place to debate the desirability of playing from memory.  Personally, I would rather get some details about what is planned.

I am more concerned about handling the glitches that currently can happen when playing some files (e.g. high-res files over wireless on an under-powered system) than I am about the issue of noise generated from access the drive. If I could load a whole album into memory or to a SSD, then the nature of the network or USB connection disappears..

Current Play From Memory only loads a single track and does not allow the user to define how much memory to set aside for MC to use. Very long tracks sometimes do not fit into the memory that MC decides to use and there can be glitches when it loads the rest of the track.

The hope would be that the user could set how much memory to use. Also, a few versions ago, MC changed from decompressing the data (e.g. flac) before loading into memory, whereas prior to that it decoded when reading from memory. The change caused problems for some people. It would be nice to have the option to do either. I would also like to see the load from disk to memory happen entirely during a track break. On some high-res files, starting the load during the last few seconds of the previous track can cause hiccups on some systems.

So, my hopes

1) User defined memory size (optional)
2) Decode before or after loading (user specified)
3) Load only during track breaks (user specified).

Also, allowing the user to specify single track load (like current) or whole album (new feature) might be useful.

One issue is how to handle gapless files, but that is not a big issue for me.

Let's keep the discuss to issues like this, or the thread will get locked.

[Blueline]

The best is if JRiver be able to copy the playlist to a SSD disk that's only for
caching, then I'd inserted a 32GB SATA SSD, SLC (Single-Level Cell)

I Have USB reserved for connection to DAC
no other USB contacts are used, as it will affect the sound
Example: Glitches

[RD James]

So, my hopes

1) User defined memory size (optional)
2) Decode before or after loading (user specified)
3) Load only during track breaks (user specified)

This largely mirrors what I hope to see as well.

For #1 - I'm still holding out hope for a 64-bit version of JRiver both for video playback performance and stability, and to allow caching of more audio data when playing music. (e.g. full SACD disc)

For #2 - I'd say that being able to specify the size of the playback buffer (decoded audio) would probably cover this. The performance issues I've had ever since memory playback was changed is the fact that JRiver tries to decode 2GB of audio as quickly as possible (very high CPU usage) and because 2GB is not enough to cache an entire SACD track. (high CPU usage in the middle of playback causing it to skip)

For #3 - I'd probably specify something like: load new tracks when only X tracks remain in the cache. Or perhaps a duration (e.g. 5-10 minutes) rather than a number of tracks. Starting caching at least one full track in advance - preferably more - would probably fix the issue I have where USB drives, network connections, or busy disks, can take much longer than the 10-20 seconds or so that JRiver currently allows for loading which can creates long pauses.

You could have it so that clearing one track out of memory prompts the loading of another, but while that would result in smooth playback, caching batches of tracks at once seems like it would be better from a power consumption point of view.
 
At the same time, I'd also prefer to limit how much I/O JRiver is doing as you could end up creating the opposite situation of what we currently have where JRiver is causing periods of very high I/O rather than periods of very high CPU usage. It's a difficult balance which probably needs to be tuned per-system so I hope we get more than "cache albums on/off".

[Blueline]

if I have 32GB RAM, I could reserve 8GB of system.
The rest 24GB can be used for the RAM disk.

RAMDISK
https://www.tekrevue.com/tip/create-10-gbs-ram-disk-windows/

[kstuart]

Yeah, I hate that when my computer has too many processes running and my Excel results come out slightly different.

Somehow you missed that Excel is exactly what a computer was designed to do, because it is not real-time like audio and video playback.

The reason that software engineers cannot understand why two "bit perfect" playbacks can sound different is because they think only in terms of digital bits, and never on the level of PC electronics.   In actuality, there is no such thing as a "digital circuit", in the sense that ALL computer electronics are analog - only the usage of the electronics is "digital".

A "bit" is simply whether the signal is 5 volts or ground. As a result, what is going on in the electrical circuits has an effect.

[kstuart]

If you're going to cite studies, please also include a link or two.

Double-blind tests:

http://www.audioasylum.com/forums/pcaudio/messages/7/70925.html

Here is a possible explanation for this and other playback phenomena, written by a DAC designer. Part one:

http://www.audiostream.com/content/qa-john-swenson-part-1-what-digital

Part Two:

http://www.audiostream.com/content/qa-john-swenson-part-2-are-bits-just-bits

[Blueline]

It means that the file(s) are loaded into RAM before playing them.  Some people think that minimizing disk access during playback improves the sound.

"Some people....."

Does that mean you not believe that it improves the sound?

[JimH]

Double-blind tests:

http://www.audioasylum.com/forums/pcaudio/messages/7/70925.html

Gordon Rankin is a very smart guy, but he's also quite an audio mystic, in my opinion.

I don't think you can rely on his test results.

[JimH]

"Some people....."

Does that mean you not believe that it improves the sound?[/size]

Let's focus on how the feature should be implemented.  For a debate on this subject, I suggest trying the hydrogenaud.io forum.

[AndrewFG]

^

MC already has a Play Track from Memory feature which plays the track from RAM. So I suppose that the Play Album from Memory will basically work in the exact same way, except that more tracks will be loaded into memory (RAM) at the same time

[Matt]

^

MC already has a Play Track from Memory feature. So I suppose that the Play Album from Memory will basically work in the exact same way, except that more tracks will be loaded into memory at the same time

The trick is that the existing Play from memory feature holds decoded data in 64-bit.  So it would just be much too huge to hold an entire album.

So I think there needs to be a layer that loads the files to memory at the start of playback (and later grows to load tracks ahead as well).

I have a stub of this coming in the next build:

NEW: Added "Options > Audio > Load files to memory at the start of playback" to totally load a file into memory when playback starts (works with APE, FLAC, MP3 -- others to follow).

Trotting in the right direction at least!

[kstuart]

The trick is that the existing Play from memory feature holds decoded data in 64-bit.  So it would just be much too huge to hold an entire album.

So I think there needs to be a layer that loads the files to memory at the start of playback (and later grows to load tracks ahead as well).

I have a stub of this coming in the next build:

NEW: Added "Options > Audio > Load files to memory at the start of playback" to totally load a file into memory when playback starts (works with APE, FLAC, MP3 -- others to follow).

Trotting in the right direction at least!

So, can you clarify what MC is doing?

From what you stated above, MC21 loads decoded data in 64-bit into memory.

MC22 now has to totally load a file into memory when playback starts.

How is that different?

Thanks!

[mojave]

So, can you clarify what MC is doing?

From what you stated above, MC21 loads decoded data in 64-bit into memory.

MC22 now has to totally load a file into memory when playback starts.

How is that different?

Thanks!

Matt said, "So I think there needs to be a layer that loads the files to memory at the start of playback . . . " It probably will look something like this:
Layer 1 would be compressed data loaded into memory. This would hold files/albums.
Layer 2 would be 64-bit uncompressed data loaded into memory. This would buffer the current track.

[millst]

Somehow you missed that Excel is exactly what a computer was designed to do, because it is not real-time like audio and video playback.

The reason that software engineers cannot understand why two "bit perfect" playbacks can sound different is because they think only in terms of digital bits, and never on the level of PC electronics.   In actuality, there is no such thing as a "digital circuit", in the sense that ALL computer electronics are analog - only the usage of the electronics is "digital".

A "bit" is simply whether the signal is 5 volts or ground. As a result, what is going on in the electrical circuits has an effect.

I was being a tad facetious. However, if you want real-time you are in the wrong place. JRiver doesn't run on any real-time OSes. Why not just buy a better DAC, one that isn't affected by these issues? Even that is probably overkill for 99% of people, who would be better served fixing their room issues or buying better speakers...

-tm

[JimH]

Let's not get into a debate about PC internals, etc.  We're going to implement playback from memory for larger files and lists of files.  Give us a week or so and then we'll be able to tell you more.

[millst]

Is "larger" defined yet?

-tm

[amsco15]

Is DLNA play affected by this feature at all?

[JimH]

No.

[dtc]

I have been experimenting with this and it does not work as I expected. It seems like it just loads one track at a time. I have not done any sophisticated analysis, just watching memory and CPU use with Task Manager. It looks like it loads one track to start. Then, for the second track the memory usage drops during the last few seconds of the first track and then starts building again while the second track starts playing. It takes about 10 seconds on my admittedly slow system to get to a a steady memory usage and there is significant CPU usage during that time. After about 10 seconds, the CPU usage drops back down and the memory usage then stays throughout the rest of the track. Then the process starts up again. Task manager shows less than 50% of memory in use. During the build up in memory usage at the beginning of each track I occasionally hear small glitches in the sound.  There is very little else running on the system. Given the extra memory available I would have expected more than one track to load at a time.  I have tried with and without the Load Files to Memory at Start of Playback checked and it does not seem to make any difference. This test was done with a 192/24 flac album on a 2.0 usb drive.

It would be nice to get some more information about how the loading happens and if there are any settings (like pre-buffering) that might affect the process. Also, just what is the logic that determines how much memory to use - it seems like it just loads one track at a time.

As I have said before, it seems like there should be options like specifying the amount of memory to dedicate to use and to force the load process to happen during silence. I am assuming that it can load a full track in much less than 10 seconds. I would hope it can do so in 2 or 3 seconds. Without that, I am afraid I will continue to get glitches.

I can try it on a faster system, but it would be nice to know just what the process is doing and what to expect before I do that.

[RD James]

I don't think the feature to load a playlist into memory is in yet, currently it only seems to be loading a single track into memory.
Monitoring the program via Process Explorer shows that it is behaving as I would expect though.

When I play a very large multichannel AIFF file with the new "load files to memory at the start of playback" option, the whole thing is loaded into RAM immediately at the start of playback.
When seeking, there is a brief spike of CPU usage to about 12% (filling a small playback buffer) and then it settles back to ~6% CPU usage on average during playback. (actively decoding audio and applying DSP)
There is no disk access at all when seeking through the file.
 
Using the old "play files from memory instead of disk" option, only about half of the file is loaded into RAM at the start of playback, and since it decodes all of this audio immediately CPU usage hits about 25% for an extended period of time (filling a large playback buffer) then settles to about 3% during playback. (is not decoding audio, but still applies DSP or has some residual CPU usage?)
About halfway through the track, or when seeking past the buffered audio, I get another extended period of 25% CPU usage and disk access while the rest of the track is decoded into memory.

[kr4]

What does this mean

Memory such as Ram
Memory such as SSD (JRiver move files to an SSD disk before playing Music)

Can you clarify this

I see that this is not "ready" yet but where does one see this option?

Never mind.  It just appeared on the latest revision.

[dtc]

Update : I had checked both Play from Memory and Load Files at Start of Playback. It appears that Play from Memory is the old method and Load at Start is the new version. With Load Files at Start of Playback only checked, I get much less CPU activity between tracks and the memory size is smaller, so I am pretty sure that is the new method. However, I still get CPU usage and memory change between tracks. It really seems like each track is being loaded into memory separately as the tracks change. For my test album (a 24/96 flac file) the 1st 4 tracks are 64 KB, 109KB, 62KB, 80 KB. Memory usage with nothing playing is 31 K. When the first file loads it jumps to 107K, an increase of 76KB, compared to the 64KB file size. A small difference is not surprising. For the second track, memory jumps to 150K, an increase of 43K, compared to a file size increase of 45K. For the third track memory drops down to 105K, a drop of 45K compared to a file size drop of 47K. For the forth track memory jumps up to 123K, an increase of 18K, compared to a file size change of 18KB. It really looks like each track is being loaded into memory at the start of each track. I looked at the transition with Process Explorer and there definitely seems to be disk activity at track change.

The good news is that Load Files at Start of Playback seems to load the compressed file quickly  and there is only a small amount of CPU used for each track change. This looks very similar to the original play from memory (MC 18 and before). Unfortunately, it does not seem to be loading multiple tracks at once.

Am I missing something?

Perhaps Jim and/or Matt can give us an update of what this first version is doing and what else to expect.

[Matt]

Right now it loads the track into memory in the first second it's playing.  Actually it loads to memory before outputting any samples (but the previous track would still be playing).

Jim is keen on making it load tracks ahead so we load the full album, but we're still in the brain storming stages for that.

[dtc]

Right now it loads the track into memory in the first second it's playing.  Actually it loads to memory before outputting any samples (but the previous track would still be playing).

Jim is keen on making it load tracks ahead so we load the full album, but we're still in the brain storming stages for that.

Thanks. So the loading of each track separately is the current implementation. So I am not going mad Seems like we are basically back to the original implementation.

For me, loading during silence seems like the best option. Maybe that can be an option if you are planning to load while still playing the previous track as the default t. I will check the transitions with large files on slow media and see how it works.

[dtc]

I just tried a classical piece (24/192) with a 400KB movement followed by a 580KB movement, on a very slow system with a usb 2.0 drive.  There was definitely a delay while loading the 580KB movement. The display switched to the new track with a timing of 0:00, but nothing played, then the display reset and started up in a second or two. So, it looks like the waiting to play until fully loaded is working, which is awesome. It would be nice if the header display did not reset, but that is a minor issue.

EDIT: I tried the same large files on a frightfully slow network connect to another system with a 2.0 USB drive and, after a significant delay, the tracks play fine, which is good news.

I did try using the new memory load with a TRemote Client and got a Playback error. I would like to be able to use this feature to make the loading of large files over a network to a client more reliable, but it is not a critical need.

[RD James]

Right now it loads the track into memory in the first second it's playing.  Actually it loads to memory before outputting any samples (but the previous track would still be playing).
Jim is keen on making it load tracks ahead so we load the full album, but we're still in the brain storming stages for that.

Ideally this would be based on the playlist and not albums so it would do something like "buffer X tracks ahead" or "keep a 2GB buffer of tracks full", not "buffer the rest of this album".
Whether it is constantly buffering new tracks (old track out  = new track in) or doing batch operations (wait until X tracks remain, then fill the buffer) is something else that would ideally have a preference.

As discussed earlier in this topic, I think this is going to require quite a bit of fine-tuning to work well and balance I/O vs CPU usage.
At least while it's being worked on, opening up these parameters might be a good idea, though I still feel like it's never going to be an option which can be a simple on/off toggle.
Not all users have the same amount of RAM - or want to allocate the same amount to buffering tracks.
Different storage devices have very different access times and transfer rates - local ssd, local hdd, usb 2/3 storage, networked storage; gigabit lan vs 802.11g wifi, online storage/3G/4G connections etc.
And I'm still holding out hope for a 64-bit build so that we can access more than ~3.5GB of RAM without the player crashing. (really starting to become a problem for video playback with the prevalence of 4K)

I just tried a classical piece (24/192) with a 400KB movement followed by a 580KB movement, on a very slow system with a usb 2.0 drive.  There was definitely a delay while loading the 580KB movement. The display switched to the new track with a timing of 0:00, but nothing played, then the display reset and started up in a second or two. So, it looks like the waiting to play until fully loaded is working, which is awesome. It would be nice if the header display did not reset, but that is a minor issue.

EDIT: I tried the same large files on a frightfully slow network connect to another system with a 2.0 USB drive and, after a significant delay, the tracks play fine, which is good news.
I did try using the new memory load with a TRemote Client and got a Playback error. I would like to be able to use this feature to make the loading of large files over a network to a client more reliable, but it is not a critical need.

Once it starts loading more than one track into memory at a time, I think this is going to be considerably better than things used to be when you're dealing with slow file access.

[JimH]

A few off-topic posts were removed.

[dtc]

Right now it loads the track into memory in the first second it's playing.  Actually it loads to memory before outputting any samples (but the previous track would still be playing).

Jim is keen on making it load tracks ahead so we load the full album, but we're still in the brain storming stages for that.

Thanks. This seems to working as planned. It sounds like we will have to wait a while for the next phase to get multiple tracks to load and to possibly use SSD. At least play from memory is once again usable for me.

Is this suppose to work from a Tremote client? Currently it errors for me.

[kr4]

Right now it loads the track into memory in the first second it's playing.  Actually it loads to memory before outputting any samples (but the previous track would still be playing).

I have tracks that are too large to load (>2Gb) and MC22 cannot play them unless I turn off this, admittedly beta, feature.

[Matt]

I have tracks that are too large to load (>2Gb) and MC22 cannot play them unless I turn off this, admittedly beta, feature.

Next build will have this:
Changed: The memory reading stuff has a hard cap at 1.5GB (since that's all we'd be able to allocate anyway).

So it won't play from memory, but hopefully it'll still play!

[AndrewFG]

Next build will have this:
Changed: The memory reading stuff has a hard cap at 2GB (since that's all we'd be able to allocate anyway).

So it won't play from memory, but hopefully it'll still play!

I guess the coolest solution for tracks (or playlists) larger than 2GB would be to fill the RAM as much as you can, then page swap a played portion of the track out of RAM, and page swap in part of the rest of the track, until the whole track has fully played out. It would obviously incur disk activity for each page swap, which probably argues for bigger pages (say 500GB) paging in less frequently, rather than smaller pages paging in more frequently..

[tyler69]

...Or releasing a 64Bit version of MC?! That is assuming the 2gb cap is due to MC being a 32bit programme (just guessing).

[RD James]

When I watch the player's memory usage it regularly goes over 1.5GB.
It seems to hit about 3-3.5GB before the player crashes when trying to play 4K videos.

Windows has been 64-bit for 11 years now and all the video components that were holding back 64-bit version of the player (particularly madVR) were updated to support it a year or two ago.
Video formats like H.265 seem to really benefit from 64-bit decoders, measuring almost twice the performance in some tests (admittedly that is an outlier rather than typical) though I'd just be happy if 4K videos didn't crash the player all the time.

Is a 64-bit version of JRiver going to happen?

[kr4]

Next build will have this:
Changed: The memory reading stuff has a hard cap at 1.5GB (since that's all we'd be able to allocate anyway).

So it won't play from memory, but hopefully it'll still play!

Thanks.  That will allow me to leave this option on but less than ideal.

[flac.rules]

Next build will have this:
Changed: The memory reading stuff has a hard cap at 1.5GB (since that's all we'd be able to allocate anyway).

So it won't play from memory, but hopefully it'll still play!

So files bigger than 1,5 GB will not play from memory at all, or will some part of the track be loaded, and then another part of the track? And does the play from memory only work on music, or does it also work on video?

[ko854]

Hi MC Team,

How about Play album from memory feature so far? Will it appear soon? I really like to use this feature.

The album is loaded into RAM or SSD (OS drive) is till OK.

Thanks.