INTERACT FORUM
More => Old Versions => JRiver Media Center 24 for Windows => Topic started by: fitbrit on March 15, 2019, 12:52:03 pm
-
I had memory playback (single file, not decoded) active. Playing FLAC files that were under 50 MB in size started up with very little perceivable delay. However, switching to a much larger FLAC file (300+ MB) resulted in a long delay (10 seconds or more of buffering).
I thought it was a memory playback issue, so I turned off the feature. The delays from switching to a larger FLAC file ceased, as I expected. However, when I tried the load decoded file to memory option, I expected the delay to be even longer as the file is first decoded and then loaded into memory. In fact, the opposite was true; the long delay before playback of the large files disappeared. It was as responsive as having memory playback turned off. I was not expecting that - should it be working this way? With FLAC files this large, I expect there is no compression going on, so I would expect the two single-file memory options to behave similarly.
Other info:
CPU i7 8700
RAM: 32 GB 2400
Playback from a NAS (which is not going to sleep between tracks as I though it might be).
-
Yep, I've noticed this as well. Been meaning to ask why, but kept forgetting.
-
One loads the file before playback starts and the other loads the file as it's starting. That's why there's a difference.
-
I wonder if we couldn't start playback already as the file is still loading. No real reason to wait until its done, no?
-
I wonder if we couldn't start playback already as the file is still loading. No real reason to wait until its done, no?
Please do.
-
I guess the whole “point” of memory playback is that there is no disk activity during the play. (So starting the play during the disk load basically nixes that “point”..)
I think the idea is (was) that in days of yore, the HDD generated power spikes on the mobo that had a negative audible impact on its DAC. Personally using a modern mobo, a modern SSD, and pushing digitally to a remote DAC (rather than doing the DA conversion onboard), I can’t notice any audible differences between in memory and not.
Nevertheless I would be hesitant to make the change lest you provoke the wrath of those audiophiles who can hear a difference..
-
I guess the whole “point” of memory playback is that there is no disk activity during the play. (So starting the play during the disk load basically nixes that “point”..)
Memory Playback should be for eliminating the impact of slow disk/network access interrupting/delaying playback, since that is a real thing which can actually happen.
An ideal memory playback system would be accessing your disk while audio is being played back from memory, to queue up the next track (or buffer multiple tracks) so that playback never happens directly from the disk/network, while keeping memory usage relatively low (<1GB).
Making an exception to start playback faster on the initial track seems acceptable to me.
I think the idea is (was) that in days of yore, the HDD generated power spikes on the mobo that had a negative audible impact on its DAC. Personally using a modern mobo, a modern SSD, and pushing digitally to a remote DAC (rather than doing the DA conversion onboard), I can’t notice any audible differences between in memory and not.
If you are hearing "interference" with disk access, USB devices etc. it is caused by bad/faulty hardware (e.g. the Schiit Modi 2 USB DAC) or setup issues like ground loops, and will produce obvious issues with playback.
Memory Playback is not a fix for these issues, as there is a never-ending rabbit hole you can go down to try and "silence" a PC's internal components when you are using a bad/faulty DAC or have ground loop issues, instead of fixing the actual problem causing this to be audible in the first place (the device/setup).
I don't have the source to hand, but I seem to recall there being a test of the Schiit Modi 2 DAC - which is known to have a faulty USB implementation that 'picks up' all sorts of interference from the computer - demonstrating how its performance was affected by things like CPU load and other USB devices being used. Memory Playback may have helped reduce these problems.
Adding an expensive USB isolator completely fixed this issue with the DAC.
But replacing the $100 Schiit DAC and $260 USB isolator with a $60 Behringer audio interface that has a properly designed USB input performed flawlessly on its own, without having to worrying about things like disk access and USB devices.
Memory Playback has a purpose, but it's not related to audio quality.
-
I guess the whole “point” of memory playback is that there is no disk activity during the play. (So starting the play during the disk load basically nixes that “point”..)
I think the idea is (was) that in days of yore, the HDD generated power spikes on the mobo that had a negative audible impact on its DAC. Personally using a modern mobo, a modern SSD, and pushing digitally to a remote DAC (rather than doing the DA conversion onboard), I can’t notice any audible differences between in memory and not.
Nevertheless I would be hesitant to make the change lest you provoke the wrath of those audiophiles who can hear a difference..
Exactly. Of course, there are people who will argue both sides of this issue, but that is exactly why memory playback was originally implemented.
It is also the case that loading data during playback, for example at the end of a track, can cause glitches on some systems. This is particularly true for large files on slow systems, including when loading high resolution files over a network. Loading everything into memory before starting playback eliminates those glitches.
-
It is also the case that loading data during playback, for example at the end of a track, can cause glitches on some systems. This is particularly true for large files on slow systems, including when loading high resolution files over a network. Loading everything into memory before starting playback eliminates those glitches.
Sure, but it's a complete waste of memory if you have a functional DAC, and unsuitable for anything outside of a dedicated media server.
That's why an ideal solution would buffer the upcoming track (or tracks) from the disk/network while the current track plays from memory.
This solves the problem while being efficient with memory usage.
-
RD - We have been over this multiple times. We disagree. Lets leave it at that.
By the way, I have a functional DAC and plenty of extra memory.