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: use foo_ramdisk per default? (Read 3825 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

use foo_ramdisk per default?

Hello,
as I still have a spinning hard drive in my PC at work (at least where my music files are stored) and the disk load is quite high very often, the use of foo_ramdisk makes sense here.
And I wanted to ask if it is possible to use foo_ramdisk per default.
So that I don't have to 'Send to Ramdisk' or 'Add to Ramdisk' every time ...
Well, it's not a big deal to be honest as I have buttons for this functions, but ... you know ... it would be nice if it is possible ...  :))

Thanks in advance!
johastl

Re: use foo_ramdisk per default?

Reply #1 –
A default on startup would be okay, so long as it has a progress dialog, and doesn't interfere with the rest of the player's use. Just so you know that it's not locked up or anything, since it probably takes a while to commit an entire music library to memory every startup.

Re: use foo_ramdisk per default?

Reply #2 –
Quote from: kode54 on
A default on startup would be okay, so long as it has a progress dialog, and doesn't interfere with the rest of the player's use. Just so you know that it's not locked up or anything, since it probably takes a while to commit an entire music library to memory every startup.
Who has enough RAM to store their entire library in memory? :)

Re: use foo_ramdisk per default?

Reply #3 –
Apparently this person who started this topic.

Re: use foo_ramdisk per default?

Reply #4 –
Quote from: MordredKLB on
Who has enough RAM to store their entire library in memory? :)
:-) It's of course not about the entire collection ...
In the end it would be perfect to have it like this: "what's in my playlist is on my ramdisk".
If I add something to the playlist it's on the ramdisk and if I remove something from my playlist it will be removed from the ramdisk.
But that would require many more amendments to the plugin I guess.
For me, the default use of the ramdisk would be a good start ... perhaps it's possible with some tweaks or other tricks ...

Re: use foo_ramdisk per default?

Reply #5 –
Quote from: johastl on
Quote from: MordredKLB on
Who has enough RAM to store their entire library in memory? :)
:-) It's of course not about the entire collection ...
In the end it would be perfect to have it like this: "what's in my playlist is on my ramdisk".
If I add something to the playlist it's on the ramdisk and if I remove something from my playlist it will be removed from the ramdisk.
But that would require many more amendments to the plugin I guess.
For me, the default use of the ramdisk would be a good start ... perhaps it's possible with some tweaks or other tricks ...
I think that could be done with a SMP script, since it can use contextual menus for tracks on playlists.

A script which sends automatically all tracks from X playlist to ramdisk would not be so difficult to do.

Re: use foo_ramdisk per default?

Reply #6 –
Wouldn't it be more effective to just increase the size of the appropriate buffer?

File>Preferences>Advanced>Playback>Buffering>Full file buffering up to (kb):

(would that be better than 'Read-ahead for local files' (kb)?)



Quis custodiet ipsos custodes?  ;~)

Re: use foo_ramdisk per default?

Reply #7 –
No. The buffer only  loads current played file, not the next one.
As far as I know, that was a limitation of the program (which doesn't know which file will be next and it's only set when the current one ends).
In that sense, I understand the use of manual ram buffering.
Standard order -> Buffer next track on playlist
Random order -> Buffer all tracks on playlist
shuffle -> Buffer all unplayed tracks on playlist

Simple.
 

Re: use foo_ramdisk per default?

Reply #8 –
I'm sorry, it doesn't seem so simple to me. Why is the default buffering inadequate? What actual gains would come from using a ramdisk on a normal system?
Quis custodiet ipsos custodes?  ;~)

Re: use foo_ramdisk per default?

Reply #9 –
I also want that feature. I don't know why but I have hiccups during playback. Maybe the discs are slow? Maybe the whole PC? It's so often that I don't use F2K at all for playback. Only for library management.

But Jriver and Roon are almost flawless. In Jriver I have select to load the decoded file to memory. In Roon there is no such option and in a recent discussion in their forum they wrote that they do not load to RAM anything.

I play various tracks over and over again. In F2K I will hear the jump. But not in the other 2.

There is already an addon. Why not a modification of it.

Re: use foo_ramdisk per default?

Reply #10 –
Quote from: 2tec on
I'm sorry, it doesn't seem so simple to me. Why is the default buffering inadequate? What actual gains would come from using a ramdisk on a normal system?
Well that are your words, not mine. It can be improved and that's a fact... whether it's inadequate or not depends on your usage and hardware I would say... It's obviously good enough for many setups. I will not discuss how people set their PC or what's good enough for some.

As already noted, current buffer only loads current file on memory. Playing next tracks takes some time while loading it to the buffer (specially if you use full buffering!). Again, foobar knows nothing about what will be the next track on some play modes and it loads the next file just after current track's end... so that means current buffering method is essentially useless on those cases.

Also i'ts pretty simple. You can spend that X time on every track change, or you can load all at once or on the background (x*n). For sure, many hdds setups work better in the second use-case, where disk access is done sequentially instead of bursts. Specially when that HDD is being accessed by other software at the same time... Sometimes that leads to hiccups, etc

Anyway, I don't get why it's questioned. I mean... if you don't care about that it's fine. But some people do. Obviously I'm not talking  about loading the entire library to ram... but just the things which will be played next or current playlist. We are in 2021, it's not 2010. We have ram enough and it can be used to improve responsiveness on software. So.. why not? There is already an addon , it can be done.
If it's not done via sdk, it can be done with a SMP script. I have other priorities right now, but I will take a look at it if it's not implemented some day.