Print

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

[Awesome Donkey]

Coming next build we'll have this:
Changed: The maximum memory playback size allocated is expanded to 4 GB from 1 GB on 64-bit builds.

Having some sort of customization for this would be great too, since I could potentially allocate up to 16 GB (well, conservatively 10 to 12 GB) for this task, however overkill that may be. Ideally, since MC is already aware of total memory (along if the system is 64-bit or 32-bit, or if the MC build is 64-bit or 32-bit), it could use that to give an option of how much to use for memory playback - say you have 16GB RAM, MC can give the option to use like 1 GB up to let's say 10 to 12 GB (leaving some for the rest of the system).

Potentially, you *could* allow up to around 3.5 GB for the 32-bit build too (or have the customization with a default of 512MB or 1 GB with selections up to 2 GB on 32-bit OSes, up to 3 GB on 64-bit OSes running MC 32-bit while leaving some for the rest of the system).

[RD James]

Having some sort of customization for this would be great too, since I could potentially allocate up to 16 GB (well, conservatively 10 to 12 GB) for this task, however overkill that may be. Ideally, since MC is already aware of total memory (along if the system is 64-bit or 32-bit, or if the MC build is 64-bit or 32-bit), it could use that to give an option of how much to use for memory playback - say you have 16GB RAM, MC can give the option to use like 1 GB up to let's say 10 to 12 GB (leaving some for the rest of the system).

Just throwing memory at the problem won't work.
The real solution is a system that caches a number of upcoming tracks to fill a set duration; e.g. cache as many tracks as necessary to keep the current track plus a 10 minute buffer full at all times.
This would finally eliminate playback issues caused by slow/busy disk/network access, while keeping memory usage at a minimum.
Even with high sample rate DSD that should remain below 1GB total memory usage, and be considerably less for lower bitrate formats.

[JimH]

This would finally eliminate playback issues caused by slow/busy disk/network access, while keeping memory usage at a minimum.

It would take a very bad system to cause playback problems.  Network access and disk access are many times faster than needed.

[tyler69]

I can imagine that playing hi-res AIF files over WIFI can cause issues, no?

[DJLegba]

It would take a very bad system to cause playback problems.  Network access and disk access are many times faster than needed.

Not so. If you can load a long enough track into into memory your HD may go to sleep, and there will be a pause when MC loads the next track. Implemented as RD James suggests, this would never happen.

[JimH]

You could do the calculation.

AIFF:
https://en.wikipedia.org/wiki/Audio_Interchange_File_Format

The article says that a minute of audio is about 10MB.

Older wifi supports 10mbits/second or about 1MB/second.  60 seconds is 60 MB.  6x what you'd need for normal PCM.  There is some "slippage" in the speed, but you can usually cut the nominal speed in half and arrive at an approximation of the real world speed.

Most wifi now is 10x that speed or better:
https://www.extremetech.com/computing/160837-what-is-802-11ac-and-how-much-faster-than-802-11n-is-it

In your own situation, you could try transferring a file between two wifi connected devices, and get a more accurate measure.

And then, you can always get hung up on antivirus problems, where some slow software wants to check every byte of every file.

[JimH]

Not so. If you can load a long enough track into into memory your HD may go to sleep, and there will be a pause when MC loads the next track. Implemented as RD James suggests, this would never happen.

If your disk is going to sleep, you could fix that.  That isn't a problem MC should have to program around.

[tyler69]

Thanks for the quick update. I was of the impression that this was already the case in the x64 version.
I do have two questions (for my understanding):
1. Why 4GB?
2. Why not make the size user selectable?

[tyler69]

You could do the calculation.

AIFF:
https://en.wikipedia.org/wiki/Audio_Interchange_File_Format

The article says that a minute of audio is about 10MB.

Older wifi supports 10mbits/second or about 1MB/second.  60 seconds is 60 MB.  6x what you'd need for normal PCM.  There is some "slippage" in the speed, but you can usually cut the nominal speed in half and arrive at an approximation of the real world speed.

Most wifi now is 10x that speed or better:
https://www.extremetech.com/computing/160837-what-is-802-11ac-and-how-much-faster-than-802-11n-is-it

In your own situation, you could try transferring a file between two wifi connected devices, and get a more accurate measure.

And then, you can always get hung up on antivirus problems, where some slow software wants to check every byte of every file.

I found a calculator https://www.colincrawley.com/audio-file-size-calculator/ and some real-world WIFI speeds in case somebody else wants to do the math: https://www.speedguide.net/faq/what-is-the-actual-real-life-speed-of-wireless-374

[DJLegba]

If your disk is going to sleep, you could fix that.  That isn't a problem MC should have to program around.

My external USB drive can't be configured. I've tried. I could buy a new one, but it works fine for me without memory playback and that's fine with me. It is, however, one example of a real-world issue that could be solved with an intelligently loaded memory buffer. Not many problems have workable solutions that start with "if people would just..."

[JimH]

My external USB drive can't be configured. I've tried. I could buy a new one, but it works fine for me without memory playback and that's fine with me. It is, however, one example of a real-world issue that could be solved with an intelligently loaded memory buffer. Not many problems have workable solutions that start with "if people would just..."

If it's a USB 3.0 drive, make sure it's plugged into a USB 3.0 port.

I think we may be permitted to expect that hardware works as it should.

[Manfred]

As an example: In my Environment I can Stream BD mkv's with 40 MBit/sec from My Server to a Media renderer over WIFI with no issues. Playback starts immediately.

[tij]

Not so. If you can load a long enough track into into memory your HD may go to sleep, and there will be a pause when MC loads the next track. Implemented as RD James suggests, this would never happen.

in that case less memory is better ... so hdd is kept busy, preventing it from sleeping

in any case ... putting hdd to sleep (spin down) is a tricky issue ... spinning disk up cause much more wear than keeping disk spinning (more so for larger drive since platter are larger and require more energy to spin up) ... getting it spot on is usually hard to achieve

so constant spin up and down will wear off your hdd much faster (not to mention consume more energy) ... so in the end need to choose right hdd for right task (aka if its NAS ... choose appropriate hdd and keep it spinning ... enterprise hdd are not that much expensive than consumer ones)

[dtc]

It would take a very bad system to cause playback problems.  Network access and disk access are many times faster than needed.

Overall transfer speeds can be very high, but the issue is with startup times, not overall speeds. Windows is not a real time OS, so you cannot guarantee what happens during transitions. That is why buffers are used.   The issue here is simply how much of a buffer to provide. Loading the whole album into memory is one solution that pretty much guarantees that there will be no transition issues when playing the album.  Loading only part of it creates the opportunity for transitions and therefore glitches. When Matt implemented loading a full undecoded album into memory, he made sure the whole album was in memory before playback started. That prevented glitches that could happen if playback started while loading was still happening.  Overall speeds are fast, but transitions can still cause problems.  I hate to say, but RD's solution also causes the chance of transition problems. In a perfect world, it would be fine. But, in the real world of Windows, it can cause transition problems, even on fast systems.

As a former real time programmer, my advise would be that no transitions is the best solution, if possible.  Otherwise, you are providing the opportunity for potential problems.

[mattkhan]

this is not a feature that I pay close attention to as I have no need for it however I always get the impression there are (at least) 2 quite distinct use cases for it.

One comes from the crowd who appear to prefer the computer to be doing literally nothing except playing music and would run the whole thing off a ram disk if they could. As far as I can tell, this group don't care about gaps between tracks.

The other is using memory playback as buffer to guard against transient issues (down to the vagaries of their playback systems).

RD James wants the latter but MC delivers the former, no?

My point being the implementation is "memory playback", the desired feature is something else that (to my mind) gets lost in the talk about how to implement memory playback.

[dtc]

Actually, I think the goals are the same for both groups. It is just a matter of degree how bad the transition is.

One of the issues is playing an album versus playing a playlist. When loading a whole album into memory, it makes sense to load the whole album. But, if you have a very long playlist (or a very long album) then you have to trade off how many tracks to load versus how much memory to use.  The same issue does come up when loading high res albums, since a high res album can, potentially, take a lot of memory.

Back to the original post, the issue seems to be how much memory to allocate and whether it should be user settable. Now, the user has no control over how much is used. And, a fixed setting is never going to please everyone. Having all options  have user settable parameters can get to be very cumbersome.  The question is whether memory playback should be one of those options with settable parameters - in particular, number of tracks and amount of memory.

[mattkhan]

That is not how I interpret the posts. One group want the computer to be idle (except for playback activity) once the selected content is available, the other want it to continue streaming, and decoding, new content into memory while playback continues. i.e. the latter group just want an in memory buffer big enough to eliminate any remotely reasonable upstream instructure issue as a concern and are happy to use the computer for that activity concurrently with playback. I think the former group are completely opposed to that.

A user controllable max memory to allocate seems useful either way though I would think you would want to be able to see utilisation of that buffer somewhere so you could decide how to set it.

[michael123]

Just throwing memory at the problem won't work.
The real solution is a system that caches a number of upcoming tracks to fill a set duration; e.g. cache as many tracks as necessary to keep the current track plus a 10 minute buffer full at all times.
This would finally eliminate playback issues caused by slow/busy disk/network access, while keeping memory usage at a minimum.
Even with high sample rate DSD that should remain below 1GB total memory usage, and be considerably less for lower bitrate formats.

That's a different feature what you suggest. Prefetch, or Cache Ahead, etc. I believe it is already working like that in movie playback

However, memory playback for music is what it is now - completely eliminate any possibility of hardware interrupt or other unexpected event during playback.
There are few hardware CD players built like that, and that's a good feature appreciated by the audiophiles -- I would even say THE FEATURE people upgraded to V23

and as Jim said, if "disk" is going a sleep, either (1) increase the inactivity timeout, (2) don't use this feature

[dtc]

That is not how I interpret the posts. One group want the computer to be idle (except for playback activity) once the selected content is available, the other want it to continue streaming, and decoding, new content into memory while playback continues. i.e. the latter group just want an in memory buffer big enough to eliminate any remotely reasonable upstream instructure issue as a concern and are happy to use the computer for that activity concurrently with playback. I think the former group are completely opposed to that.

A user controllable max memory to allocate seems useful either way though I would think you would want to be able to see utilisation of that buffer somewhere so you could decide how to set it.

I though RD's suggestion was based more on how long it can take to load a full album rather than wanting to do something in addition during playback.  Loading just enough to stop playback issues eliminates the long time it can take to load an album, especially a high res album or an album loaded over a network. If, in fact, the user wants to be doing other activities during playback, I agree it is a very different situation.

[RD James]

It would take a very bad system to cause playback problems.  Network access and disk access are many times faster than needed.

It's not an issue if the disk is already spinning, you're playing over a fast local network connection, and the disk/connection is not being used by anything else.
If the disk has gone to sleep, there is heavy disk/network access from other processes, or it's being sourced from a remote connection, it's not difficult to make playback in Media Center stall when changing tracks - or even when seeking if you're playing back SACDs that are too large to be fully decoded into memory.

However, memory playback for music is what it is now - completely eliminate any possibility of hardware interrupt or other unexpected event during playback.

The current implementation of Memory Playback does not do this.

1. Memory Playback disabled. Keeps disk/network access busy and prevents it from idling. This keeps playback gapless so long as it is fast enough (or free enough), since it doesn't allow the drive to sleep - though it also means that playback can be interrupted if another process saturates the connection.

2. Load full file (not decoded) into memory. Ensures that the current track cannot be interrupted by slow I/O access. Allows disks/NAS/network connections to sleep/idle and may introduce delays when changing tracks.

3. Load full album (not decoded) into memory. With large tracks this causes significant delays to the start of playback. With too many tracks, it falls back to memory playback being disabled (after that delay). May use a significant amount of memory. But does at least guarantee that playback will not be interrupted and track changes should be instantaneous, if the playlist is small enough to fit in memory.

4. Load decoded file into memory. Behaves the same as #2, except it uses significantly more memory. The one advantage that it has, is that it will cache SACD tracks, while loading non-decoded files does not.
 
 
 
What is needed for seamless playback is to load the current track in memory (not decoded), start playback as soon as that happens, and then load at least one more upcoming track in memory.
That way you ensure that playback remains gapless and cannot be interrupted by slow access, without wasting a lot of memory.
 
Ideally it would cache multiple tracks to ensure that the buffer is of sufficient length for playback over a very slow disk/network connection to remain gapless, since some tracks may be very short.
A buffer of 5-10 minutes should be more than enough, while still using very little memory.
It could even be repurposed as a power-saving feature by having a cache of say 10 tracks and only refilling it when that drops to 1 or 2 upcoming tracks.

The only thing this system would still fail on is SACD ISO playback.
I don't know that there's a good solution for that other than either caching the entire ISO file, or decoding tracks into memory. It's actually likely to use less memory to cache the entire ISO file than the decoded tracks for many albums.

[michael123]

What is needed for seamless playback is to load the current track in memory (not decoded), start playback as soon as that happens, and then load at least one more upcoming track in memory.

That's for #2, when only the single track is preloaded at a time, agreed.

A buffer of 5-10 minutes should be more than enough, while still using very little memory.

I lost you again, why do you want to limit the buffer? the purpose of memory playback is to have.. playback from memory.

[RD James]

I lost you again, why do you want to limit the buffer? the purpose of memory playback is to have.. playback from memory.

Keep 5-10 minutes of upcoming tracks in memory. That's typically going to be 2-3 tracks depending on length - or many tracks if they are very short, such as albums with 15-30 second interludes/skits etc.
When a track moves out of that cache and starts playing, add more tracks to the cache until the total is at ~10 minutes again.
 
This way you are never playing directly from disk, only tracks that are already cached in memory.
So gapless playback, seeking, and skipping, would always be instantaneous as it's never loading directly from the disk.
 
You would limit the size of this cache to limit the amount of memory that Media Center is using, because most people don't have a dedicated box with 64GB of RAM solely for music playback.

• 10 minutes of stereo DSD128 would be ~1GB.
• 6ch DSD64 ~700MB.
• 24-bit 192 kHz PCM ~400MB.
• 16-bit 44.1 kHz PCM ~100MB.

Solves the problem while also keeping memory usage reasonably low.

[dtc]

I play mostly albums on a dedicated system, although a slow on, with an external drive.  I much prefer to load everything at the beginning if possible, rather than potentially interrupting the music to reload, even reloading between tracks, especially for high res albums. Reloading while music  is playing definitely needs to be avoided. It takes longer to load everything up front, but then there is no potential for problems during playback. A longer than normal delay between tracks is also undesirable. Since it is a dedicated system, there is no reason to minimize memory usage. For me, partial loading of the album is not desirable. I like the current load (not decoded) to memory which loads the full album.  Doing multiple loads is not desirable.

Allowing the user to specify the amount of memory to use would enhance the option.

[RD James]

I play mostly albums on a dedicated system, although a slow on, with an external drive.  I much prefer to load everything at the beginning if possible, rather than potentially interrupting the music to reload, even reloading between tracks, especially for high res albums. Reloading while music  is playing definitely needs to be avoided. It takes longer to load everything up front, but then there is no potential for problems during playback. A longer than normal delay between tracks is also undesirable. Since it is a dedicated system, there is no reason to minimize memory usage. For me, partial loading of the album is not desirable. I like the current load (not decoded) to memory which loads the full album.  Doing multiple loads is not desirable.

Allowing the user to specify the amount of memory to use would enhance the option.

There are many different failure states for the "load album" memory playback option which causes it to play tracks directly from the disk instead - and it does this after you have potentially waited several minutes for it to attempt loading the tracks into memory.
The one benefit to it, is that if your playlist is small enough, and the sample rate/bit-depth is low enough that it does fit into memory, it will allow the disk to sleep for longer.
 
A system that starts playback as soon as the first track is loaded into memory, and then keeps an additional buffer of tracks full - no matter how big the playlist is - is superior in every way.
I can't think of any scenario that would cause Media Center to take more than ten minutes to load the next track, breaking gapless playback.
If it was going to take that long, it would take five hours to pre-load 30 of those tracks into memory prior to playback using the "load album" option.
 
And it would achieve that while keeping memory usage below ~1GB.

[dtc]

RD - The problem is that the reloading may cause glitches in the playback or excessively long gaps in some cases. The idea of memory playback is to have no disk activity during playback of an album, which means reloading has to happen between tracks, which does not work for gapless playback and can produce a long gap in some cases.

As I said above, playback of albums and playback of playlists are different. I mainly play albums and do not want any disk activity during the playback.

Letting the user set a track number and memory limit would be useful. But, to eliminate the ability to load an entire album would be a huge step backward.

I agree that there should not be "failure states" after waiting for several minutes. It seems like it would be very easy to calculate the number of tracks and the amount of memory needed before loading anything. That would allow the program to do the right thing from the start.  The overall strategy of loading full albums would not have to change to implement that fix.

[RD James]

RD - The problem is that the reloading may cause glitches in the playback or excessively long gaps in some cases. The idea of memory playback is to have no disk activity during playback of an album, which means reloading has to happen between tracks, which does not work for gapless playback and can produce a long gap in some cases.

It wouldn't affect playback because the currently playing track would already be in memory.
 
If it were decoding tracks into memory during playback, rather than copying them into memory, the CPU usage from that could potentially be an issue with older systems when playing back DST-compressed multichannel DSD files. I'm not asking for tracks to be decoded into memory though, as that inflates the memory usage significantly for no benefit.
 
The only time disk activity affects playback is if it's playing directly from that disk, rather than memory.

[dtc]

Obviously, we completely disagree on this. The traditional idea of memory playback is to completely eliminate disk activity. What you are saying is that disk activity during playback is fine. Well, sorry, that is not acceptable to many who want memory playback.
 
Your assertion that the only time disk activity affects playback is if playback is happening directly from disk is the issue. You may believe that, but many do no agree with you. First, many believe that any extra activity during playback is detrimental because of electrical issues. Second, you are assuming that disk activity has absolutely no effect on the timing of playback. There is a very large amount of evidence that this is not true, including playback with MC. MC on Windows is simply not a perfect real time system. In a perfect world I might agree with you. But, glitches do happen during transitions. I heard it regularly before the load decoded album into memory was implemented.

Again, your proposed solution does not address the issue of detrimental effects due to electrical effects during playback and does not recognize that disk activity during playback can cause unexpected glitches.  Unfortunately, PCs and Windows are not perfect systems.

[RD James]

Obviously, we completely disagree on this. The traditional idea of memory playback is to completely eliminate disk activity. What you are saying is that disk activity during playback is fine. Well, sorry, that is not acceptable to many who want memory playback.
 
Your assertion that the only time disk activity affects playback is if playback is happening directly from disk is the issue. You may believe that, but many do no agree with you. First, many believe that any extra activity during playback is detrimental because of electrical issues.

It is one thing to have disk activity interfere with playback when the media player is playing directly from that disk. That's a real thing, and it's possible to demonstrate that happening with Media Center.
It is another to imagine a scenario where disk activity could have any impact on playback whatsoever when the media player is playing a track that is already in memory.

Second, you are assuming that disk activity has absolutely no effect on the timing of playback. There is a very large amount of evidence that this is not true, including playback with MC. MC on Windows is simply not a perfect real time system. In a perfect world I might agree with you.

There is very little if any evidence of this, just a lot of quackery.

But, glitches do happen during transitions. I heard it regularly before the load decoded album into memory was implemented.

That's not caused by disk activity, it's caused by the next track not already being in memory, and is one of the reasons why I'd like to see Memory Playback further improved.
By default, Media Center has six seconds to load the next track. If the disk is asleep or busy, that may not be enough time. Even extending this to the maximum of 20 seconds may not be enough.
And if you used the "load decoded file in memory" option, the spike of CPU usage as it tries to decode the entire track in those six seconds could also glitch playback.
On my old PC it was easy to set up a reproducible test where playback of DSD would glitch the last 20 seconds of a track when that option was enabled.

Again, your proposed solution does not address the issue of detrimental effects due to electrical effects during playback and does not recognize that disk activity during playback can cause unexpected glitches.  Unfortunately, PCs and Windows are not perfect systems.

The only possible scenario I can think of is where accessing a hard drive would cause audible interference is if you have a DAC with a broken USB implementation.
So far the only DAC I know of like that is the Schiit Modi 2 (and possibly other Schiit DACs).

It's one of the very few DACs where USB filtering actually does make a difference to the audio quality:


Meanwhile an $80 Behringer DAC performs flawlessly due to a proper USB implementation:


If your DAC affected by this issue, the solution is to replace it. Not to spend $325 on USB filtering, or do something like building a dedicated system from esoteric parts and filling up all the system memory before playback starts because your broken DAC is so "sensitive" to interference.
And that even assumes that there would be any difference in the interference over the USB port which is directly linked to the HDD load. Even with one of those broken DACs I wouldn't be surprised if it took multiple failures for that to occur.

The good news is that there's already an option for you in Media Center which dumps everything into memory before playback if you have faulty hardware, so you don't have to spend time arguing against making tangible improvements to the memory playback system.

[dtc]

Sorry, what I discussed is not quackery. You are free to believe that but others do not.  It has been discussed over and over again in lots of forums, with no resolution.  There is no need to continue that discussion here.

The original purpose of memory playback was to eliminate disk activity during playback.  That should continue to be its main purpose within MC. If you want to use it differently, that is fine with me. But, removing the current ability to load a full album into memory would be a big loss for MC.

Time to return to the original post.

I fully support the addition of an option to let the user control the number of tracks and the amount of memory. But it should not come at the expense of loading a full album into memory.


EDIT :  Here is a link to a discussion about the issues that computer noise can cause of audio output of a DAC, even if the bits are exactly correct. It is a known issue for DAC designers.  The issues they discuss are one of the reasons that memory playback with a minimal amount of computer activity is considered important by many.  John Swenson and Gordon Rankin are pretty well known in the DAC business. Rankin, of course, was the first to implement asynchronous USB, which is pretty much the standard today.

https://www.audioasylum.com/forums/pcaudio/messages/12/126159.html

[mattkhan]

This is why I said there are 2 quite different features in here (hence I'd split the threads to allow those distinct features to be discussed separately)

[RD James]

Sorry, what I discussed is not quackery. You are free to believe that but others do not.  It has been discussed over and over again in lots of forums, with no resolution.  There is no need to continue that discussion here.

The original purpose of memory playback was to eliminate disk activity during playback.  That should continue to be its main purpose within MC. If you want to use it differently, that is fine with me. But, removing the current ability to load a full album into memory would be a big loss for MC.

Time to return to the original post.

I fully support the addition of an option to let the user control the number of tracks and the amount of memory. But it should not come at the expense of loading a full album into memory.

Memory Playback is to prevent disk/network activity affecting audio playback.
That doesn't mean all disk access should be eliminated from the computer, it means that all playback should only be from files that are cached in memory rather than directly from the disk - ideally while using as little memory as possible to achieve that goal, since most people don't have an entire computer dedicated solely for playing back music.
Media Center does not have an option for this yet.

Where in my posts did I say that the "load album" option should be removed?
I do think it's a misguided option that should never have been added, as its inclusion does nothing but add credence to some ridiculous ideas about how computers work, but now that it's there I doubt JRiver will remove it.

EDIT :  Here is a link to a discussion about the issues that computer noise can cause of audio output of a DAC, even if the bits are exactly correct. It is a known issue for DAC designers.  The issues they discuss are one of the reasons that memory playback with a minimal amount of computer activity is considered important by many.  John Swenson and Gordon Rankin are pretty well known in the DAC business. Rankin, of course, was the first to implement asynchronous USB, which is pretty much the standard today.

https://www.audioasylum.com/forums/pcaudio/messages/12/126159.html

Evidence requires data.
Snake oil salesmen are obviously going to claim that snake oil is effective.
As I have demonstrated above, it is possible to build a DAC which is sensitive to noise over the USB bus, but that is a broken design.
If your DAC is sensitive to these sorts of issues, it is performing worse than an $80 device and should be replaced.

[dtc]

Evidence requires data.
Snake oil salesmen are obviously going to claim that snake oil is effective.
As I have demonstrated above, it is possible to build a DAC which is sensitive to noise over the USB bus, but that is a broken design.
If your DAC is sensitive to these sorts of issues, it is performing worse than an $80 device and should be replaced.

Gordon Rankin and John Swenson are not snake oil salesmen.

[JimH]

I don't know John Swenson.  I like Gordon, but I don't agree with everything he says.  He isn't selling Snake Oil though.

[dtc]

I don't know John Swenson.  I like Gordon, but I don't agree with everything he says.  He isn't selling Snake Oil though.

Do you disagree with their comments in the link I posted? If so, feel free to explain.

[JimH]

You can continue the discussion on your own.

It would be nice to see a slightly less contentious discussion.  Snake Oil has a place, but maybe not here.

[RD James]

Gordon Rankin and John Swenson are not snake oil salesmen.

If you're being told that USB filtering or cables costing several hundred dollars are required, or that disk access in your computer has any bearing on audio playback when the track is already stored in memory, you're being sold snake oil.
If their DACs require these things to sound good, then their DACs are poorly designed since a mass-produced $80 DAC from Behringer does not suffer from these issues.
Now I know what you're thinking - their DACs must be so much better that they're now revealing these issues that a cheap device like that isn't capable of. Yet somehow DACs from companies like Benchmark Media - often held up as the reference that other DACs should be compared against - have no such issues.
 
CPU usage, rather than disk usage, can affect playback.
That generally should not be an issue for most systems unless you have an old CPU and are using very small playback buffers. The "load decoded file in memory" option should prevent that from happening - though it's not an option that I like using.
 
My concern with memory playback is about actual reproducible issues that could be fixed in Media Center without having to fill all available memory - only requiring it to keep a buffer that is a few tracks ahead of the currently playing track, instead of loading those tracks from disk on track change.
 
I currently have 13 drives in my main system and it makes no difference to music playback whether they're all sitting idle or are all working at 100% usage - which is several GB/s of data being moved around.
What does make a difference is if the drive or network connection that the music is on is very busy with other operations when it is time for Media Center to change tracks, as the current memory playback options offer no protections against that.

[audioriver]

The original purpose of memory playback was to eliminate disk activity during playback.  That should continue to be its main purpose within MC.

Do you mean to completely eliminate disk activity during playback? That sounds impossible because the disk is controlled by the OS, which constantly accesses hard disks (especially the one where the OS itself resides), whether the user requests it or not. Unless you mean for MC to behave similarly to what happens during BD/DVD burning, where the writing device is locked and no other program is allowed to touch it? Seems like an impossible analogy.

2. Load full file (not decoded) into memory. Ensures that the current track cannot be interrupted by slow I/O access. Allows disks/NAS/network connections to sleep/idle and may introduce delays when changing tracks

4. Load decoded file into memory. Behaves the same as #2, except it uses significantly more memory. The one advantage that it has, is that it will cache SACD tracks, while loading non-decoded files does not.

Thanks for the info. I'm still a bit confused about the difference of these two. In the case of 2, when/how is the file eventually decoded? Does it occur in the RAM? Doesn't the file need to be decoded anyway to be played back and wouldn't it require the exact same amounts of CPU/RAM usage as 4?

[dtc]

Do you mean to completely eliminate disk activity during playback?

The idea is to reduce disk access as much as possible. If you disable antivirus, network, other programs and other such activities,  load the entire album into memory and just do nothing but let the music play, then you can pretty much eliminate disk activity. Obviously, if Windows decides for some strange reason to access a disk, then there is not much you can do about it.

[kr4]

The idea is to reduce disk access as much as possible. If you disable antivirus, network, other programs and other such activities,  load the entire album into memory and just do nothing but let the music play, then you can pretty much eliminate disk activity. Obviously, if Windows decides for some strange reason to access a disk, then there is not much you can do about it.

Isn't the system disc that is doing all this distinct from the remote ones that store/play the files?  It is in my system.

[dtc]

Isn't the system disc that is doing all this distinct from the remote ones that store/play the files?  It is in my system.

Sometime they are the same disk, sometimes they are different disks. In any case, the idea is to minimize any disk activity, no matter which disk.  The idea is to stop any extraneous electrical noise by minimizing any type of unnecessary activity.  You can never eliminate everything, but the more the better.

[RD James]

Thanks for the info. I'm still a bit confused about the difference of these two. In the case of 2, when/how is the file eventually decoded? Does it occur in the RAM? Doesn't the file need to be decoded anyway to be played back and wouldn't it require the exact same amounts of CPU/RAM usage as 4?

With "load full file (not decoded)" the file is stored in memory and played back from there, keeping a very short buffer of decoded audio.
I think it may be linked to the prebuffering setting, so it would be 2-20 seconds of decoded audio.
During playback there will be a constant but very small amount of CPU usage to keep this buffer of decoded audio full, but no disk access.
 
With "load decoded file into memory" the entire track is decoded in memory as quickly as possible and played back directly.
During playback there should not be any disk access or CPU usage to decode the track, but there is a big spike of CPU usage at the start of playback or ~20 seconds before the track changes, as Media Center tries to decode it as quickly as possible.
 
DSD is particularly ill-suited for this option.
Since Media Center has a 64-bit playback engine, decoding multichannel DSD has severe memory requirements - longer tracks can fill several gigabytes of RAM - even if the DFF track or disc image itself is much smaller than that.
The one thing in its favor is that it's the only option which loads tracks from SACD ISOs into memory. Other memory playback options do not load the ISO in memory, they play back directly from disk.
 
If you have a quad-core CPU without hyper-threading, it's possible for the spike of CPU usage upon track change with DSD to actually interrupt the end of the currently playing track.
The amount of memory it uses, the spikes of high CPU usage on track change, and the fact that it can actually make playback more prone to interruption, means that it's not an option I recommend using.

[JimH]

The idea is to reduce disk access as much as possible. If you disable antivirus, network, other programs and other such activities,  load the entire album into memory and just do nothing but let the music play, then you can pretty much eliminate disk activity.

For those in doubt, I don't think that disk activity influencing sound has ever been demonstrated or proven.  The possibility is just  speculation that gets passed around and eventually becomes myth.

The sound itself is coming from a DAC and amplifier that are usually at some distance from the disk.

Let's just agree that the feature does no harm and satisfies some people.  If we can improve it, we will.

[AndyU]

I think before you get too hung up about the possible sonic benefits of memory playback you should play some music and then fire off as many disc accessing processes as you can until your pc is on its knees and ask yourself whether you can hear a difference. If not, it is unlikely that reducing what is already a negligible amount of activity under normal conditions is worthwhile.

[runes]

Why you don't add an option to load the entire album (or a few files ahead of the currently played file instead of only one file) DECODED into memory? If it is a RED Book CD it wouldn't be more than 700 MB and by doing this it will completely eliminate Disk and CPU activities during playback of the entire album. My system disk is different than my music and it seems that implementing it wouldn't need to have a rewrite but only a small modification to your memory loading algorithm. I usually play an album and don't use playlists and I know of quite a few audiophile users who are using the same setup as I do and will appreciate it a lot.