So here is a crazy thought I just had while thinking about the low memory issues some empeg users are having with large hard drives and/or third party programs running on the empeg. Would it be possible for the linux kernel to automatically compress and decompress the contents of RAM? If this worked it seems like we could make the empeg appear to have more RAM than it actually does. It even seems like there is some existing linux code to do this although for newer versions of the kernel. Thoughts?

-Mike

It sounds as an excellent idea! So much for a comment coming from a linux-imparied one as I am

Mmm.. the player apparently locks down all of its memory, to prevent paging, which would also prevent the compression scheme from kicking in.

Of course, we could hack the kernel to ignore the locking..

Cheers

Of course if the player is buffering compressed audio into memory then trying to compress it again will just be a waste of processing power. This might be good to experiment with, however.

Even if it is buffering uncompressed audio I suspect the result will be much the same. That said, some people do have very tight memory constraints, so I guess even a few percent might help them.

Of course if the player is buffering compressed audio into memory then trying to compress it again will just be a waste of processing power

True, but I get the impression that the player stores a copy of the fid database in memory. If that is correct it is probably at least a couple megs on any decent sized player and ought to compress very well (mostly text) unless it is already in a compressed format. Anyway, getting this to work is probably beyond my skills, but I thought it might interest our resident kernel hackers if they are bored some day.

-Mike

True, but I get the impression that the player stores a copy of the fid database in memory.

You need a TiVo cachecard!

I get the impression that the player stores a copy of the fid database in memory.

It does. And you can probably compress it reasonably well. The Karma database uses a more efficient database scheme, so maybe that'll turn up in one of the later v3.0 alphas or betas.