Login

logo6


CRAM Download

Description:
CRAM - Compressing ram-drive, this is a series of drivers that I hope to develop in create a ram drive that can support more data than it's allocated memory.

Update code versions 0.10 - 0.40 are tested and bug free.  The 0.40 version is faster and uses smaller files to support restarts.

A working 0.50 version that supports a larger ram drive than memory (default is 1TByte) works, but you must manually unmount the before rebooting.  I don't know why yet.

Lots of work still to be done.

Submitted On:
28 Jun 2011
Submitted By:
Earl_Colby_Pottinger (Earl Colby Pottinger)
Submitted On:
28 Jun 2011
File Size:
185.17 Kb
Downloads:
47
License:
Public Domain, use as you wish.
File Version:
0.10 - 0.50
File Author:
Earl_Colby_Pottinger
Rating:
Total Votes:0

Comments  

 
0 # RE: CRAM — thatguy 2011-05-20 21:21
nifty little widget, could work great with some of those new pci SSD drive and guys with loads of ram.
Thank you Earl !
 
 
0 # RE: CRAM — thatguy 2011-05-21 14:43
You know with enough ram, this would be a fantastic way to do audio recording as large track counts can often swamp a hardrive.
 
 
0 # Not that good. — Earl Colby Pottinger 2011-05-23 15:20
AGMS's software is far better written than anything of mine.

The only advantage my code has over his is the versions 0.10 and 0.20 are bare-bones and thus very very fast.

The code that I am still working on will offer storage spread across multiple drives but at present AGMS's software is the gold standard.
 
 
0 # RE: Not that good. — thatguy 2011-05-23 17:06
Quoting Earl Colby Pottinger:
AGMS's software is far better written than anything of mine.

The only advantage my code has over his is the versions 0.10 and 0.20 are bare-bones and thus very very fast.

The code that I am still working on will offer storage spread across multiple drives but at present AGMS's software is the gold standard.


Earl what is the practical adressing limit of your code in terms of size ? I am thinking a 4-8gb size ramdisk might be perfect for audio and video capture needs. Certainly would help with frame dropping etc when the hdd saturates.

Have you thought about a acess API for things like Bmedia to include calls so that things being streamed in can be held in memory and put to disk virtually, this would be a serious help with buffer overun problems when capturing with a pci style device and the hdd saturates, given the performance of the current SATA stack, it would be very helpful for a potential developer looking to do audio and video editing and recoding.
 
 
0 # CRAM Limits — Earl Colby Pottinger 2011-05-27 20:51
As far as I can tell the present versions 0.10 and 0.20 are limited to what Haiku will let you assign in an array, which I believe is 2GB. Rewriting to use the Create_Area() function will probably I believe limit you to Haiku's memory limit with is something is limited to the physical memory installable in your hardware.

However, I would expect any well written audio software to also use all the memory available in your computer.

CRAM`s later versions will be limited to BeFS/HaikuFS`s limit of 2**48 bytes.
 
 
0 # RE: CRAM Limits — thatguy 2011-05-28 07:47
Quoting Earl Colby Pottinger:
As far as I can tell the present versions 0.10 and 0.20 are limited to what Haiku will let you assign in an array, which I believe is 2GB. Rewriting to use the Create_Area() function will probably I believe limit you to Haiku's memory limit with is something is limited to the physical memory installable in your hardware.

However, I would expect any well written audio software to also use all the memory available in your computer.

CRAM`s later versions will be limited to BeFS/HaikuFS`s limit of 2**48 bytes.



Heh, you would expect well written audio software to use the ram, but it is mostly all written for windows. You know how memory handling in windows is. hehe.
 
 
0 # RE: RE: CRAM Limits — andrewzx1 2011-05-28 19:02
Memory handling in Windows is pretty good. The use of handles, i.e. pointers to pointers that can be swapped out, is quite flexible and very very efficient for low memory situations. Remember that Windows was originally designed to run in 4 MB RAM. A little less actually.
 
 
0 # RE: RE: RE: CRAM Limits — thatguy 2011-05-28 22:06
Quoting andrewzx1:
Memory handling in Windows is pretty good. The use of handles, i.e. pointers to pointers that can be swapped out, is quite flexible and very very efficient for low memory situations. Remember that Windows was originally designed to run in 4 MB RAM. A little less actually.



but XP has problems with buggy caching and its best to turn it off and write directly to disk. I have been running a home studio for long enough to see which is better. I run a raid config for recording now.

again I have never seen a ramdisk implementation for windows either, not that they don't exist I am sure one does somewhere. Not only that but effects take up lots of ram and the 64bit os's have trouble with VST's. So its 32b or your screwed which has problems with lots of ram.

Its fustrating. Thankfully these problems are less serious with haiku.
 
 
0 # Corrections — Earl Colby Pottinger 2011-06-01 13:39
I found an error in version 0.30, do not use unless you fix the problem in the read() call. If you look at the write() call where the VM_Status == VALID_TRACK you will notice where it say write_section, now look into the read() function where the same test is done. There it will say read_count ... that should say read_section, change, recompile and you should be fine.

I hope to upload the corrected version and version 0.40 on the weekend.
 
 
0 # Size limits — Earl Colby Pottinger 2011-06-01 13:42
Presently CRAM is limited to 2**44 bytes in size not 2**48, sorry for the mistake.
 


Please register to post comments

Search Files

Search For: 
Search File Titles: 
Search File Descriptions: 

The Largest BeOS/Haiku Software Repository