LMS-squeezelite - great corrections on the way

Are you running squeezelite with a super large replay buffer??? 

I am recommending such a setup in public for several years - since the beginning of squeezelite-times to be exact. I've been running and suggesting full-track-ram-caches even before squeezelite times all over the places and even got disbarred from the JR River Media Center forum for proposing such a BAD thing - around 15??? years back.  Meanwhile full-track caching is a pretty common way to handle tracks in the streaming world. 

Truth to be told. There were some slightly annoying flaws associated to full-track-ram-caching in the LMS-squeezelite environment... ...and there's been a recent change. And I thought it is worth to write about it.


Just for you to recall. What full-track-ram-caching does is following.  An entire track gets pre-processed and loaded into a RAM cache on squeezelite - the client - at the beginning of replay. That takes just a few (single digit) seconds and causes quite a high CPU load during these few seconds.

The advantages are at least twofold

  1. You don't see continues network load, which you'll see if you run small buffers with squeezelite
  2. You lower your base CPU load during playback. In my case instead of 2-3% continuous I see something between 0 and 1%. Substantially lower! 
  3. (For the die-hard environmentalists out there: You can even save some power.)
Overall we're seeing a lower impact on the chain during replay. A higher efficiency - the main goal of most of the optimizations you'll find on this blog. 

Limitation: If you run a very low key streaming client with limited RAM this won't work. 

Now. For years there has been a weird behaviour associated to this setup.
  1. Somehow the playlist management of LMS got mixed up. LMS couldn't handle a fully 
    buffered track. It messed up the playlist pointers. E.g. if you would have used "Add Next", the server would not have played that next track. There have been more of related issues.
  2. Another issue was that long tracks were cut off a couple of seconds before replay ended
These issues "were" annoying. Still I could live with it.

There've been several reportings and discussions about the subject over at squeezelite forums and github. For a long time these issues were simply ignored. Recent developments in streaming, where the bulk-loading of tracks into a cache becomes common practice might have changed the thinking. I also communicated above advantages more than once out there.

A fellow developer aliased as philippe44, who's contributing quite a lot to LMS, recently took the challenge to look into the subject. He dissected the whole process on LMS and squeezelite. He had to learn how this LMS dinosaur (never touch a running system - especially if it is called LMS) works in this crucial area. 

I don't know how much time it took him to figure it all out. Some long lonesome hours...

He finally found several related issues. On LMS AND squeezelite. And yes - he figured out potential solutions, got these implemented and made them public.

Yesterday I installed the latest LMS-github version and the updated squeezelite.

And... ...Wow, It works. The entire weird behaviour is gone. What a relieve. A late Christmas gift.  What a great achievement. I love it. I would have never expected that someone ever touches this lower communication layer of LMS and squeezelite. It's extremely tricky. You could mess up (ten-)thousands of streaming installations out there. And now it works flawless. I've been hoping for this for years.

These specific corrections of course impact just a small group of die-hard tweakers who are following my tracks for now. I am pretty sure though this group of people will love it. Some other might even feel tempted to jump on that train. ( Also highly recommend for the audiophiles out there to give it a try)

Most of you have to wait until these corrections make it into public. You'd at least need a squeezelite version 2.x and a nightly LMS version later than January 7th 2024. Those of you who run my optimized squeezelite versions from github can update their installations already now. I merged the changes yesterday.

Enjoy.



1 comment:

  1. Thanks for the heads-up on this (and your other recent updates). It took me a little time last year to work out that the Squeezelite buffers were impacting LMS. Just downloaded 8.4 and the most recent Squeezelite and so far, so good! Well done philippe44!

    Do you know what happened to Allo? They'll be missed.

    ReplyDelete