Use ramfs rather than tmpfs in RAMDisk.

[Snoopy8]

Not sure how many people use RAMDisk but for me, it provides better SQ than playing music on disk or from network drive.  This is enabled in SnakeOil / Hardware tab.  (And use Browse tab to push music to RAMDisk).



My NUC has lots of free memory, but I allow for plenty of spare room.  There are 2 ways to enable RAM disk, tmpfs and ramfs.  From AK in the Wiki
 

tmpfs
tmpfs has more checks and balances. You'll never run out of memory with this type. If your system runs out of space, the Operating System will automatically swap out unused memory blocks into swap space. The upside is increased stability. The downside is memory swapping incurs a penalty and may result in lessor audio quality.

ramfs
This is the more unstable version of a RAM disk. The Operating System will not swap out your memory. If you specify a size that's too big and the system has run out of RAM, the whole machine will freeze in ithe worst case scenerio. The upside is you are assured of the lowest possible latency in music playback. The downside is you got to really know what you're doing.

Based on above advice, been conservative and using tmpfs until I (just) found out that it impacts latency.  For reference, running SO 1.3.0 on Ubuntu Server 22.0.4 LTS with real time kernel. System load average about 1.5, with CamillaDSP running convolution room correction. playing music using LMS/Squeezelite. CPUset is enabled with CPU 0, 1 for system and 1, 2 for user.  


This is typical max latency using ramfs


Did not realise how bad tmpfs affected the max latency.

So, I hope I know what I am doing, and will now use ramfs from here on.  On the Pi, there is a lot less free memory, but will leave some room below the free memory limit.

[agent_kith]

So, I hope I know what I am doing, and will now use ramfs from here on.  On the Pi, there is a lot less free memory, but will leave some room below the free memory limit.

You'll be fine as long as you make sure you don't run of RAM, which is kind of OK with computer playback.

Do not be influenced by lower latency is always better mantra. It's more about the profile, which really isn't possible with a normal cyclic test. You'll really need to bin the latency into "bins", and look at it from a frequency domain, i.e. cyclicscope. I hope to implement this in the WebApp some day, unsure when though. That will be more useful, however we should also avoid the "is better" concept, as this is just one variable of a somewhat complex (if not outright chaotic) puzzle.