Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Feature Request: 64-bit RAM-Disk (Read 4641 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Feature Request: 64-bit RAM-Disk

64-bit RAM-Disk, please...

Re: Feature Request: 64-bit RAM-Disk

Reply #1 –
64-bit RAM-Disk, please...

Re: Feature Request: 64-bit RAM-Disk

Reply #3 –
I feel like instead of requesting the 64-bit RAM-Disk (presumably for better playback quality), it would make more sense to have a component that decode entire file to ram, then starts playback?

I can't say this should bring any SQ improvement theoretically other than it might "lessen" some electrical interaction between kicking the cpu/hard-drive on.

Re: Feature Request: 64-bit RAM-Disk

Reply #4 –
Youz do realized the ramdisk component was done as a joke and not anything for "audiophile" playback, right? Right?

Re: Feature Request: 64-bit RAM-Disk

Reply #5 –
Quote from: mudlord on
Youz do realized the ramdisk component was done as a joke and not anything for "audiophile" playback, right? Right?
I don't think they realized that but I didn't either--why would Peter of all people post a "joke" component??  I'm not saying it's NOT a joke, but what/who gave you that info?  The statement Peter (?) makes on the component page that "Temporary copies exist only during the application lifetime," does sound like a leg is being pulled unless "lifetime" was a bad analogy for "until the application is closed."

Re: Feature Request: 64-bit RAM-Disk

Reply #6 –
Quote from: mudlord on
Youz do realized the ramdisk component was done as a joke and not anything for "audiophile" playback, right? Right?

I've used it on diskless LAN based system.
Quis custodiet ipsos custodes?

Re: Feature Request: 64-bit RAM-Disk

Reply #7 –
Quote from: sveakul on
I don't think they realized that but I didn't either--why would Peter of all people post a "joke" component??  I'm not saying it's NOT a joke, but what/who gave you that info?

It was a reaction to this thing: https://help.foobar2000.org/troubleshooter/components/482398a390566e59
JPlay promised the wonders of jitter-eating through foobar2000 or JRiver, for a hefty price tag.
By means of playback from RAM. So Peter posted that component. With an appropriate smiley.

But it isn't that dumb - had it even been able to spin down and shut up a HDD ... meanwhile, that sits in a quiet box.

Re: Feature Request: 64-bit RAM-Disk

Reply #8 –
The RAM-Disk component is not a serious component meant to be used. It works as advertised though - it copies stuff temporarily to RAM to make playback clumsier. That doesn't make playback any better.

If someone really needed an actual RAM disk (for example for performance reasons), boxerfan88's suggestion is a good way to do it.

Quote from: 2tec on
I've used it on diskless LAN based system.
Why? Nothing prevents you from playing from LAN directly and it's much more pleasant to play without waiting for copying to finish.

Re: Feature Request: 64-bit RAM-Disk

Reply #9 –
Quote from: Case on
Quote from: 2tec on
I've used it on diskless LAN based system.
Why? Nothing prevents you from playing from LAN directly and it's much more pleasant to play without waiting for copying to finish.
Back in the day, LANs were slow and if the network was busy, playback could be interrupted, as I personally discovered. The ram drive component alleviated this.

the lengths people will go to be dismissive of others is an indication of something
Quis custodiet ipsos custodes?

Re: Feature Request: 64-bit RAM-Disk

Reply #11 –
Porcus beat me to it. That is exactly what the output buffer is for.

Re: Feature Request: 64-bit RAM-Disk

Reply #12 –
That is not a solution, in fact setting the buffer to 30 secs also affects other settings like DSPs, etc. which may introduce undesirable effects in some use cases. I would advise to use the buffering options at the Advanced preferences page.

If those settings are properly implemented, I would say they substitute a RAM disk -for a single track- when setting a value high enough.

Re: Feature Request: 64-bit RAM-Disk

Reply #13 –
Increasing output buffer is the best solution to fight against playback stalling. It will cause DSP adjustments to take longer to be audible when tweaking settings, but that has zero effect on playback. When settings are correct there is nothing to worry about.

Over a decade ago when RAM Disk component was released advanced preferences didn't have the options it has now. There was only the "Full file buffering up-to (kb)" setting, which is almost as silly as RAM-Disk. It will load a file to RAM right before playback and on slow sources where it might be needed would 100% cause a huge delay before the copying finishes and actual playback starts.

Re: Feature Request: 64-bit RAM-Disk

Reply #14 –
Well, again, it may be silly for you.

I may use DSPs and need to swap them during playback (or using VST), therefore increasing output buffer is not an option. It may work for your use case, fine. Full buffering of a file, with lower output buffer works fine for that specific use case.

You are supposing having a delay before playback is less desirable than having it during playback and swithing DSPs, which is just your use case. Not saying the RAM disk should be brought back (and for sure, not for audiophile reasons), but I do see the utility of full buffering for multiple files (which can be done on background), which also alleviates the delay at playback start.

Re: Feature Request: 64-bit RAM-Disk

Reply #15 –
Just to clarify, I do not support any unnecessary buffers. You are supposed to use the default 1 second output and no extra buffering under normal circumstances. Optimal playback is where everything you do happens instantly without a delay and without glitches.

I suggest using the output buffer for fixing glitching due to system struggles because it helps against both slow source medium and slow source format. It can even help against DPC latency issues. With local or SMB accessed LAN files the OS should already cache the files when they are accessed and the advanced config prebuffer settings should have zero effect.