MPD 0.24 and Input Cache

[SerbJ]

From reading old threads on "input cache" it seems like most don't think it was working.  Threads were a couple years old though.  With 9.3.0 Moode / MPD 0.24 I still think it is not.  I allocted 1G via MPD config and loaded a good number of albums to the queue, but no change to memory usage.  Looked via "system info" and "free -h" command.  maybe I'm looking at something wrong?  Others?

[Nutul]

From reading old threads on "input cache" it seems like most don't think it was working.  Threads were a couple years old though.  With 9.3.0 Moode / MPD 0.24 I still think it is not.  I allocted 1G via MPD config and loaded a good number of albums to the queue, but no change to memory usage.  Looked via "system info" and "free -h" command.  maybe I'm looking at something wrong?  Others?

Maybe the check should be performed before AND after MPD has started, with different input cache values - maybe MPD allots its cache at startup (haven't seen the code, so I can just speculate here).

I remember setting my input cache from 512K to 2G (I am on whole-disc FLAC + CUE...) because sometimes I was experiencing some weird clicks at tracks change... and increasing the cache DID solve the issue. Cannot remember what MPD version it was, though... just moOde was in its early 8.x.x stage.

[Tim Curtis]

After searching the MPD repo I would conclude that "input cache" is an unfinished, experimental feature and there is almost no documentation on how it actually works except for source code. I should prolly label it as "experimental" in the MPD Config screen.

Best to leave it as "Disabled".

I'm curious though as to why a music player input cache is needed. Linux already caches files in RAM.

[SerbJ]

After searching the MPD repo I would conclude that "input cache" is an unfinished, experimental feature and there is almost no documentation on how it actually works except for source code. I should prolly label it as "experimental" in the MPD Config screen.

Best to leave it as "Disabled".

I'm curious though as to why a music player input cache is needed. Linux already caches files in RAM.

I think the default was 512K, and given my Pi has 3G available, thought it might be easy tweak.  The files are all on a near full "fast" 256G USB drive plugged into the 3.0 port side.  After finding the old posts, thought I'd tr to find out if it was actually doing something.

[TheOldPresbyope]

From the MPD manual

Configuring the Input Cache

The 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)

I would be surprised that adding tracks to the cache would change the memory usage. I'd expect the cache to be a fixed-sized carve out.

As for its advantages, I've never felt the need for them on any moOde player of mine. YMMV, of course.

As Tim says, It still looks rather experimental which is dev-speak for  use at your own risk.

Regards,
Kent

[SerbJ]

From the MPD manual

Configuring the Input Cache

The 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)

I would be surprised that adding tracks to the cache would change the memory usage. I'd expect the cache to be a fixed-sized carve out.

As for its advantages, I've never felt the need for them on any moOde player of mine. YMMV, of course.

As Tim says, It still looks rather experimental which is dev-speak for  use at your own risk.

Regards,
Kent

I thought that was further down in the manual:

Buffer Settings


Do not change these unless you know what you are doing.
Setting                                   Description
audio_buffer_size SIZE       Adjust the size of the internal audio buffer. Default is  (4 MiB).

[TheOldPresbyope]

From the MPD manual

Configuring the Input Cache

The 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)

I would be surprised that adding tracks to the cache would change the memory usage. I'd expect the cache to be a fixed-sized carve out.

As for its advantages, I've never felt the need for them on any moOde player of mine. YMMV, of course.

As Tim says, It still looks rather experimental which is dev-speak for  use at your own risk.

Regards,
Kent

I thought that was further down in the manual:

Buffer Settings


Do not change these unless you know what you are doing.
Setting                                   Description
audio_buffer_size SIZE       Adjust the size of the internal audio buffer. Default is  (4 MiB).

I don't understand what you are trying to do but the input cache is not the same as the audio buffer. Per the manual,

Code:

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.

You can flush the cache at any time by sending SIGHUP to the MPD process, see Signals.

If you enable the input cache in moOde's MPD configuration screen then you'll see this input_cache block show up in /etc/mpd.conf

As I said, I don't use it. There may be others who'll care to comment.


Regards,
Kent

[SerbJ]

It was only a response to: "which is dev-speak for use at your own risk."

When I saw: "Do not change these unless you know what you are doing.", it made me laugh because by default, I don't!

I was just trying to inject a little humor.

I'm sure I am not the 1st person to look at those parameters and assume bigger is better.

[Tim Curtis]

It was only a response to: "which is dev-speak for use at your own risk."

When I saw: "Do not change these unless you know what you are doing.", it made me laugh because by default, I don't!  

I was just trying to inject a little humor.  

I'm sure I am not the 1st person to look at those parameters and assume bigger is better.  

lol, no prob :-)

Sometimes I wonder of there are too many settings in moode

[TheOldPresbyope]

It was only a response to: "which is dev-speak for use at your own risk."

When I saw: "Do not change these unless you know what you are doing.", it made me laugh because by default, I don't!  

I was just trying to inject a little humor.  

I'm sure I am not the 1st person to look at those parameters and assume bigger is better.  

Gotcha. Sorry I was so slow on the uptake.

The nature of audio nervosa is never to be satisfied with “good enough”.
 
The nice thing about s project/product like moOde is that no matter how badly things get mucked up you’re always just a re-flash away from a fresh start.

Regards,
Kent