semi-configurable memory optimization

i know that the empeg's memory cache is very well thought out. but from the wave file dropout thread and my own observation, its been seen that spinup times are different for each drive, and the caching doesn't account for this.

i propose the hdstress program (which shows spin up time IIRC) record the # of seconds to (spin up + seektime) into flash for each drive, and let the memory handling compensate for differences.

i.e. if the spinup time + seektime ~7 seconds, then at all times, the next track is cached 7 seconds worth to prevent any pauses, and the rest of the memory dedicated to caching the current file. but this changes from format to format... that means 1204kb of memory for a wav file (172kb/sec * 7), 168kb for a 192kbps mp3 file, etc. for the current file, it should start spinning up again 7 seconds before it will run out of data (when only 1204k is left in the cache for a wav file, etc.). if spinup was 10 seconds... the cache sizes and triggers should be modified accordingly.

i'm sure the above is being done somewhat presently, but i'm gathering that the # of seconds is hardcoded, and spinup time is not accounted for.

The dropout could also be caused by paging activity. If the player allocates a bit too much cache, this could cause pages of the player's binary to be pushed out of memory. As soon as any code-path hits one of these pages, the player will pause until the disk is spun up and the page is read back.

Has anyone who is seeing the wave dropouts tried the reserve_cache= option in config.ini?

If the player allocates a bit too much cache, this could cause pages of the player's binary to be pushed out of memory. As soon as any code-path hits one of these pages, the player will pause until the disk is spun up and the page is read back.

man mlockall

The car-player never, ever, pages out. (The Rio Central player can, but even there all the code needed to come back from sleep is mlocked.)

I even have a feeling we needed to hack the kernel to disable a sanity check on the total amount of mlocked memory.

Peter

Ok, cool. I hadn't checked myself until just after I sent off the email. The player's VM and RSS sizes are not completely identical, but are close enough to assume that the mlockall works as expected.