Sound Tweak Rpi4

[TheOldPresbyope]

Blackadder  

[the_bertrum]

This suggests to me the cache need not be very big if size confers no advantage.

I agree, from my observations with this, the larger memory just fills up with tracks that have already been played. As long as the input buffer is bigger than the single largest file in a collection, it will be big enough.

[hestehandler]

This suggests to me the cache need not be very big if size confers no advantage.

I agree, from my observations with this, the larger memory just fills up with tracks that have already been played.  As long as the input buffer is bigger than the single largest file in a collection, it will be big enough.

That is not accurate. Logically the minimum size will be the sum of the size of the two largest tracks you have. While one track is playing from the cache, the next is being loaded into the cache.

[the_bertrum]

This suggests to me the cache need not be very big if size confers no advantage.

I agree, from my observations with this, the larger memory just fills up with tracks that have already been played.  As long as the input buffer is bigger than the single largest file in a collection, it will be big enough.

That is not accurate. Logically the minimum size will be the sum of the size of the two largest tracks you have. While one track is playing from the cache, the next is being loaded into the cache.

But it doesn't look like that's what is happening, it would appear the "next" track is loaded into the input cache at the point that it begins playing so the cache has the currently playing track plus any previously played tracks, there appear to be no future tracks in there.

[hestehandler]

This suggests to me the cache need not be very big if size confers no advantage.

I agree, from my observations with this, the larger memory just fills up with tracks that have already been played.  As long as the input buffer is bigger than the single largest file in a collection, it will be big enough.

That is not accurate. Logically the minimum size will be the sum of the size of the two largest tracks you have. While one track is playing from the cache, the next is being loaded into the cache.

But it doesn't look like that's what is happening, it would appear the "next" track is loaded into the input cache at the point that it begins playing so the cache has the currently playing track plus any previously played tracks, there appear to be no future tracks in there.

I just checked the network traffic with vnstat, and it appears you are right. Tracks are loaded as they start playing rather than being pre-loaded. Apologies. The input_cache is rather more crude than I imagined.

[the_bertrum]

The input_cache is rather more crude than I imagined.

Yes, it would appear we all expected it to do more than it appears to because what's the point of it otherwise?

[TheOldPresbyope]

@hestehandler

I just checked the network traffic with vnstat, and it appears you are right. Tracks are loaded as they start playing rather than being pre-loaded.

Ooh, why didn't I think of doing that? +1

 Apologies. The input_cache is rather more crude than I imagined.

No apologies needed. We were all taken in by the sales pitch in the docs.

Regards,
Kent

[kit1cat]

Let's hope it's a work in progress.

[hestehandler]

Right @TheOldPresbyope and @the_bertrum. Perhaps we should try to define the logic for how this input_cache ought to work and then append it to this issue on Github: https://github.com/MusicPlayerDaemon/MPD/issues/603

• Files should be loaded fully into the cache before playback starts, so that there is no network activity during playback.
  
• If the playlist contains more files than can fit the cache, then the loading of continuous album tracks should be prioritised (to enable gapless playback). Otherwise cache pruning and loading can be done between tracks.
  

I checked for the largest file on my server and it was almost 1GB. Users with wifi connection to their NAS would under the above mentioned scheme have to wait for some time before playback starts, but I suppose that just can’t be helped, unless there is a fall-back functionality to loading in chunks, which I suppose is better than no caching at all.

Thoughts?

[kit1cat]

The Github article is dated July 2019, I thought the input_cache was a new feature?