Enabling ramroot feature that resides in the Euphony Expert settings section means that the Euphony OS root filesystem (partition of the boot disk with kernel, system packages and application packages) will be loaded to RAM after boot. After booting to ramroot, the kernel and all programs will start by using their program files located on a 'virtual' disk in RAM memory (named zram0), as opposed to being loaded from an actual storage device). This usually benefits SQ. It's not entirely clear why, but a lot of people agree that it does (not just on Euphony).
Before you decide to use it permanently, make sure to make an honest comparison with and without it. If you don't hear clear improvements in SQ with ramroot there are no other reasons to use it - it does bring additional consideration and potential risks.
In addition to the system disk partition, Euphony uses 3 more partitions:
For the ramroot topic, it's crucial to understand item 3. - data partition.
Euphony uses data partition (mounted on /data) to store:
Here is the most important part to understand: when you enable ramroot with default options (nothing is selected), only system partition will be loaded to RAM. Other partitions, including data partition will be not!
Let me assure you that this is already enough to see a bump in SQ and with this default configuration all Music services should be able to function as usual. Some system wide changes should be applied with caution and it's always better to be out of ramroot before applying them: changing hostname, turning on WIFI access (another Expert option), update, revert etc...
There is one change you have no control over: Roon Core automatically updates to a newer version.
Roon program files are on the system disk and when Roon updates itself (you should be able to see a pending update on your Roon client) while in ramroot, changes to Roon program files will not persist automatically. You will have to save those changes to the system partition by clicking: 'Save root fs to disk'. Note that this is the only case when 'Save root fs to disk' is needed.
If you forgot to do that, Roon will next time start again with the old version. Hopefully, the newest version of Roon will not have introduced config changes incompatible with the previous Roon version (remember, data partition is not in RAM and all Roon config changes made in the new version will be saved to disk as they happen and used by the old Roon version when you restart the system).
Now, knowing and understanding everything above should be enough to use ramroot to your satisfaction or decide not to use it at all.
However, some people that run Euphony from removable device expect, (either because of their previous experience with ramroot on other systems or because they hope that by eliminating any disk access in the system they can further improve SQ), that they can completely remove that boot device after booting in ramroot.
This is not the case! At least not with the default configuration which still fully uses /data partition on the disk. With default configuration, removing the boot device while in ramroot will produce unpredictable and most likely harmful results!
For those who still want to see if their system can sound even better when disk access is completely eliminated, we have provided a couple of options: 'Copy app config to RAM' and, if selected, an additional 'Exclude roon dir' option appears.
Before we go explain these options, note that they are not intended for running Stylus or Roon Core in ramroot! They are intended for people who want to run Endpoint music services like StylusEP, RoonBridge, NAA and HQPlayer. These services don't require music files, music db or cache, they only need their config files.
If the above is completely understood, we can proceed to explain these options.
When 'Copy app config to RAM' is selected prior to enabling ramroot this will, upon reboot, after the system partition is already loaded to RAM, copy the content of .appdata folder from disk data partition to /data/.appdata folder on RAM disk.
It is very important to note that we use data partition for 3 things and with 'Copy app config to RAM' we omitted item 1. - Music files and cache. These will be unavailable while using ramroot with 'Copy app config to RAM' option selected.
While your Stylus/Roon music library may contain content on NAS, all your musical content on /data/Music will become unavailable. Cover art cache for Stylus (which also stores covers for albums on NAS storage) will also be unavailable. Stylus should be able to handle this without any issues but for Roon Core we have some problems reported. On one user's installation, Roon Core became confused when losing access to library folder /data/Music while in ramroot and getting it back out of ramroot - Roon Core doesn't want to scan /data/Music anymore. This is a pending issue you should be aware of if you use Roon and want to, against our advice, run Roon Core in ramroot with 'Copy app config to RAM' selected.
Another problem with Roon Core is that its database can become very big (especially if you use online music providers like Tidal or Qobuz). With 'Copy app config to RAM' Roon db, which resides in /data/.appdata/roon, may not fit your available RAM. Euphony will calculate this and warn you, suggesting you also select: 'Exclude roon dir'. This will exclude /data/.appdata/roon folder while /data/.appdata is copied to RAM.
Admittedly, it seems confusing to provide options related to Roon if those options are not intended for running Roon Core under them. They are here for users who already have Roon Core installation in place and already have Roon database filled but the user decides he wants to try the machine as endpoint machine, running StylusEP, RoonBridge or some other endpoint music service on it. Without 'Exclude roon dir' option, Euphony would not be able to use 'Copy app config to RAM' because /data/.appdata would not fit in RAM with /data/.appdata/roon in it. Deleting Roon Core DB is not an option since the user can still decide to use the machine to run Roon Core in the end.
When you run ramroot with 'Copy app config to RAM' selected there is an additional button present: 'Save app config to disk'. This button is not normally required as Euphony will, upon graceful shutdown (using the 'Shutdown' menu item), save all config changes from RAM to disk. However, if machine power is abruptly cut off, configuration changes will be lost. To prevent this, you can use 'Save app config to disk' to ensure your recent changes are preserved.
Important reminder: if you remove your boot device after booting it to ramroot with 'Copy app config to RAM' remember to attach it again before shutdown - otherwise, any changes you make while in ramroot will be lost!
To summarize: 'Copy app config to RAM' is strongly not recommended for Roon Server and Stylus, and users who insist on trying it must be aware of the risks and reduced function:
We only recommend 'Copy app config to RAM' for users who are booting from ejectable media like USB sticks, and only if using Endpoint services like Roon Bridge, NAA, or StylusEP. It does not make that much sense to use this option when you boot Euphony from internal devices like SSD or Optane since you cannot remove them anyway which is the main point of this option.
RAM Requirements
Generally, without using 'Copy App data to RAM' 8Gb total RAM will be enough.
4Gb is the bare minimum and only works under certain conditions - read below!
When you enable ramroot Euphony will try to calculate if you have enough RAM to go into ramroot.
If A is the total RAM available on your system at the moment of calculation and S is the size of the current boot partition then Euphony checks if A - S > 1.8Gb.
If you chose 'Copy app data to RAM' and D is the size of your app data then the check is: A - S - D > 1.8Gb.
If you chose 'Exclude roon dir' and R is the size of your roon dir then the check is: A - S - D + R > 1.8Gb.
Euphony wants to keep 1.8GB of RAM free even in ramroot to ensure normal functioning.
While Euphony is up and not playing with empty playlist all running applications will not take more than 200MB of your memory so your A is fairly close to your total RAM.
The value of S (root filesystem size) depends on your installation:
When the Euphony is booted from USB stick that was generated by burning a Euphony image to it then its default system partition occupies 2.5Gb!
When Euphony is booted from an internal disk or other media which was made by Euphony Install function or when it is booted from secondary partition (generated by 'Complete Installation') on image-generated USB then the system partition occupies only 1.8Gb.
Why the difference? Because the Euphony USB installation generated from the Euphony image additionally contains an archive (0.7Gb) of it's root filesystem. This archive is used in Install/Repair/Complete functions and it is not copied to the target system partition - installed partitions are without it.
So for someone who has only 4Gb RAM and boots from USB stick made from an Euphony image, the only way to make ramroot work is to boot from a secondary partition before enabling ramroot:
To check the current partition you booted from, go to Settings -> Library, expand External drives, click on the eye icon to show system partitions. Look for the partition that has '/' in the 'Attached to' column. If the last number in the first column is 2 then you are booted from the primary system partition. If the last number is 3 then you booted from the secondary partition. You will also be able to see that the primary partition has less free space than the secondary one.
So, with A=3.8 and S=1.8 you can just make it with 4Gb total RAM.
We are aware that all of this sounds rather complicated but be reminded that ramroot is an Expert option - don't use it if you are not comfortable with this complexity and always remember: while it may work for many, it is not fully tested and we do not fully support it (like all Expert setting options as stated in Disclaimer at the start of the Expert section).
Article ID: 14
Category: Euphony Web Application
Date added: 16.09.2019 11:01
Views : 5617
Rating (Votes): (34)
Powered by Help Desk Software HESK, in partnership with SysAid Technologies