RAM disk vs large Squeezelite buffer?

[koko6969koki]

Hello again!

Right now I'm experimenting with playback from the RAM disk from the Snakeoil beta features section,
but I find it not very practical with a large music collection.
The problem is with the file browser in the web interface - it hangs when I try to go deeper in subfolders, the hourglass keeps spinning and nothing happens.
I can select and transfer to RAM disk only the folders that are in the root of the HDD.
Since on my SnakeOil PC's internal drive I have the A-Z/artist names subfolder structure,
the RAM disk (with the present state of the file browser) is useless to me
since i can't dig deeper in the folders in order to select single subfolders that I want to add to it.

I can access the music folder and ram disk folder from other computers in the network an do the copying from there,
but it is not very practical and defies the simplicity of a small headless SnakeOil component in my hifi rack.

Because of this, I would like to experiment with Squeezelite buffer options mentioned here:
https://www.snakeoil-os.net/wiki/Players...queezelite
-b <stream>:<output> Specify internal Stream and Output buffer sizes in Kbytes

Do I apply it in the OS web interface under ALSA configuration options?
If i decide to revert it to the original values, do I just click on the RESET button?

There are some posts on Audiophilestyle forum that are very enthusiastic about large Squeezelite buffer values:
https://audiophilestyle.com/forums/topic...ent-897936
Since I have 8GB of RAM, I will try the recommended -b 2097152:2097152 settings from the post linked above.

What are your thoughts on Squeezelite buffer values?
How playing with large Squeezelite buffer settings would compare to the playback from RAM disk?
Is it, from the practical aspect, the similar/same thing achieved in a different way?

If I have opted for 2GB:2GB buffer sizes, does it mean that If click "play" on a folder that is less than 2GB,
all the files are loaded to RAM and the HDD is not active during playback?

Thank you for the effort of bringing us the great sounding OS and constantly improving it!

EDIT:
I have discovered that in the web file broser I can go deeper in some folders and in some I can't.
I can't find any regularity and I can't figure out what causes this - it might depend of number of files and subfolders, or some characters in file/folder names.
I'm 99.99% sure that in file/folder names I don't have any special characters out of the UTF-8 set.
Anyway, for now, this behaviour makes RAM disk more or less unusable in my everyday usage scenario, so I have to put my money on Squeezelite buffers.

[koko6969koki]

Just for reference, here is the example of the folder (Nick Cave discography) that can't be opened in SnakeOil web based file browser...

[koko6969koki]

I have successfully set the buffer sizes, but it is too late to evaluate SQ differences since the neighbours are sleeping. :)
I'm wondering if it is possible test disk activity in realtime while the music is playing?

[agent_kith]

I have successfully set the buffer sizes, but it is too late to evaluate SQ differences since the neighbours are sleeping.
I'm wondering if it is possible test disk activity in realtime while the music is playing?

Are you using the latest Snakeoil firmware? That should fix the folder problem (The problem is the & character, which is now escaped).

As for buffer vs RAM, I guess try both and find the best sound.

In theory, under perfect conditions - low buffer but enough RAM for your music should give you the best result. But there are several variables that will throw the theory out the window - e.g. power delivery, RAM specs, etc.... So really the key is to find the best balance.

Hence, Snakeoil - it's music your way..

[koko6969koki]

Thank you for the fast answer! :)

You said "low buffer but enough RAM". How is this exactly working? 

My idea was/is to avoid disk activity as much as possible, since I have a SSD,
and I have read that some manufacturers (for example Innuos) are saying that SSDs are a source of some high frequency electrical noise,
that can pollute the signals and could be detrimental to the sound quality.
In their higher end products they do use SSDs, but they have separate power supplies, separating them from the rest of the electronics.

This was the reason that I liked the RAM disk idea.
And if the same thing could be accomplished with a large RAM based buffer, it could be even more elegant solution since there would be no need to manually add music to RAM disk before each play.

But, as I already have said, I have no clue how this Squeezelite buffer thing actually works, so I could be on the wrong trail. :)
I was hoping that with large buffer sizes, all the files will be loaded in RAM and the SSD will not be active during playback.

---

Regarding the latest firmware, I was postponing the update, since I'm using LMS and Squeezelite
and I have read in the "Snakeoil Firmware - 1.1.9 (Blind Testing Update 9)" topic that there are some problems with LMS,
so I have decided to wait a little bit more and to do the upgrade after all the small bugs are ironed out.

---

If I decide to try the latest firmware, is it possible to go back to the 1.1.8 if I encounter some problems?
Do I just drag and drop the old .fw file in the SnakeOil window?

[agent_kith]

Thank you for the fast answer!

You said "low buffer but enough RAM". How is this exactly working? 

Set a RAM disk size that's appriopriate (e.g. 1 or 2 album size), but use a smaller buffer for squeezelite. Because all your playing music is already in RAM, there's little point in creating another buffer (just going to add more processing time).

My idea was/is to avoid disk activity as much as possible, since I have a SSD,
and I have read that some manufacturers (for example Innuos) are saying that SSDs are a source of some high frequency electrical noise,
that can pollute the signals and could be detrimental to the sound quality.
In their higher end products they do use SSDs, but they have separate power supplies, separating them from the rest of the electronics.

This was the reason that I liked the RAM disk idea.
And if the same thing could be accomplished with a large RAM based buffer, it could be even more elegant solution since there would be no need to manually add music to RAM disk before each play.

But, as I already have said, I have no clue how this Squeezelite buffer thing actually works, so I could be on the wrong trail.
I was hoping that with large buffer sizes, all the files will be loaded in RAM and the SSD will not be active during playback.

This depends on the quality of the RAM sticks I guess. A reason why I'm kindda interested in Ryzen CPUs. Memory has direct access to the CPU, unlike Intel.

There's actually a tweak where you can load the OS from a USB stick (or from Network) onto RAM, and then have everything run in memory. Meant to put up a wiki on how to do this, but havn't had the time to do this properly.

Regarding the latest firmware, I was postponing the update, since I'm using LMS and Squeezelite
and I have read in the "Snakeoil Firmware - 1.1.9 (Blind Testing Update 9)" topic that there are some problems with LMS,
so I have decided to wait a little bit more and to do the upgrade after all the small bugs are ironed out.

---

If I decide to try the latest firmware, is it possible to go back to the 1.1.8 if I encounter some problems?
Do I just drag and drop the old .fw file in the SnakeOil window?

Yes, you can re-upload the older firmware to get to the previous state.

[koko6969koki]

Thank you for the fast answer!

You said "low buffer but enough RAM". How is this exactly working? 

Set a RAM disk size that's appriopriate (e.g. 1 or 2 album size), but use a smaller buffer for squeezelite. Because all your playing music is already in RAM, there's little point in creating another buffer (just going to add more processing time).

The idea behind using large Squeezelite buffers was to try them instead of RAM disk.
I don't intend to use both at the same time.
I wanted to try what works best in my case.
The one advantage that large Squeezelite buffers have over RAM disk is that I can just browse and play music using a simple Android control app on my tablet.
There is no need to go back to Snakeoil OS interface and use file browser for file transfers to RAM disk each time when I want to play something different.

I did some initial tests yesterday and the results look promising.
I have installed nmon http://nmon.sourceforge.net/pmwiki.php on my Snakeoil NUC and via SSH I was able to monitor disk I/O activity during music playback.



At the beginning of each track played, there is only a single burst of disk activity that seems shorter than one second (maybe it is that short because files are loaded to RAM buffer from SSD)
and after that there where no further signs of any disk activity during the whole playback time. Yay!

Ok, RAM disk has an (slight?) advantage that all the files in the playlist are loaded to RAM before I start playing them, so there is no disk activity at the beginning of each song while it is being loaded in the buffer.
But in a real life usage, does it matter that much, since the loading time of one song is less or close to one second?

I have tried very long files, used some of my recordings that are almost two hours long (disk activity during loading was of course longer),
and tested the buffer by randomly jumping backward and forward over the player time line.
There wasn't a smallest sign of disk activity at any point, so I can assume that the files are fully loaded and playing 100% from RAM?

Now, the question is are there any other benefits of using the RAM disk over the large custom Squeezelite buffers?

I have yet to fully test the sound quality differences.
The first impressions are that there is (maybe!) more 3D space and air, and that the presentation is more relaxed and finely layered.
But maybe this is just me expecting to things sound better!

I have to listen more!

[agent_kith]

The idea behind using large Squeezelite buffers was to try them instead of RAM disk.
I don't intend to use both at the same time.
I wanted to try what works best in my case.
The one advantage that large Squeezelite buffers have over RAM disk is that I can just browse and play music using a simple Android control app on my tablet.
There is no need to go back to Snakeoil OS interface and use file browser for file transfers to RAM disk each time when I want to play something different.

Ah I get you now.

Ok, RAM disk has an (slight?) advantage that all the files in the playlist are loaded to RAM before I start playing them, so there is no disk activity at the beginning of each song while it is being loaded in the buffer.
But in a real life usage, does it matter that much, since the loading time of one song is less or close to one second?

It's really hard to say. If you can disable buffers altogether, then a RAM disk might be best, but then again that's under perfect conditions.

I have tried very long files, used some of my recordings that are almost two hours long (disk activity during loading was of course longer),
and tested the buffer by randomly jumping backward and forward over the player time line.
There wasn't a smallest sign of disk activity at any point, so I can assume that the files are fully loaded and playing 100% from RAM?

It's very hard to say. My experience with this is when I used to have more than 1 earth/ground point in my system, increased disk activity will create audible high frequency noise. My fix is to really just re-design my audio setup to only ground to a single point (In my case the DAC).

Now, the question is are there any other benefits of using the RAM disk over the large custom Squeezelite buffers?

I have yet to fully test the sound quality differences.
The first impressions are that there is (maybe!) more 3D space and air, and that the presentation is more relaxed and finely layered.
But maybe this is just me expecting to things sound better!

I have to listen more!

As long as it sounds better (imagine or real), it's worth doing. Before you do this, make sure you setup process priority and run anything you deem critical to be in RT. Once you are certain you have everything running like clockwork (pun intended), then repeat this RAM/buffer experiment.

Process priority will eliminate some variables, making your assessment then more accurate.

[koko6969koki]

Thank you!

Today I was playing with Snakeoil a little bit more.
Since I have a couple of Squeezeboxes, an original Slimdevices V3 and a Touch, I have concentrated on LMS first, since I wanted to make a multiroom system with my NUC running Snakeoil + LMS.

But after I started exploring MPD, I have discovered that I like it's sound even better!
Snakeoil with MPD sounds really impressive! You have done a great job!
It is much closer to my MacMini running Audirvana+, in some aspects even better, so it seems that MPD will be my player of choice for "serious" listening.

So, naturally,  I wanted to do the similar RAM buffer thing that I have achieved with LMS and Squeezelite.

Here https://www.musicpd.org/doc/html/user.html I see that there is a similar setting for MPD called Input Cache:
 
Configuring the Input CacheThe input cache prefetches queued song files before they are going to be played. This has several advantages:

• risk of buffer underruns during playback is reduced because this decouples playback from disk (or network) I/O
  
• bulk transfers may be faster and more energy efficient than loading small chunks on-the-fly
  
• by prefetching several songs at a time, the hard disk can spin down for longer periods of time
  

This comes at a cost:

• memory usage
  
• bulk transfers may reduce the performance of other applications which also want to access the disk (if the kernel’s I/O scheduler isn’t doing its job properly)
  

To enable the input cache, add an input_cache block to the configuration file:
input_cache {
size "1 GB"
}
This allocates a cache of 1 GB. If the cache grows larger than that, older files will be evicted.

 
The only problem is that I don't know how to apply this setting.

I have tried to locate the mpd.conf file, and the only one I was able to find is /var/www/scratch/mpd.conf
which seemed to be an unusual location according to the MPD literature that I've found online.

Anyway I decided to give it a go, and I tried to edit it with Nano. 
The problem is that edits don't "stick"!
I can open the mpd.conf file, add the cache setting and save it,
but when I start MPD playback, the edit that i have done just disappears from the configuration file. 
The same thing happens when I reboot the machine.

How can I make edits to mpd.conf permanent?
And, maybe the better question is am I editing the right file?!
Or, is there some other way to apply this input cache setting to MPD?
Out of despair  I have even tried the player setting field in Snakeoil web interface that worked for Squeezelite, but no luck!

[agent_kith]

How can I make edits to mpd.conf permanent?

For now, you have to modify the mpd.conf.template file under /var/www/players/<MPD_Version>. Then save and restart the players will work.

The caveat is this tweak will be gone when you update the firmware.

Hopefully from Snakeoil 1.2.1 onwards I can make this more flexible.