Thread: October update

Hi guys!

It's been a while now. As I explained earlier some setbacks, personal issues
and technical problems got in the way of the project.

A few weeks ago, I finished updating all sourcecode and used libraries to
their latest versions. Including the compiler. Boy! That was a big leap, code-wise.

Anyway, I thought I should post a where-are-we-now thread.
And I got some exciting news. Progress-wise.

First. NoTec is going to redesign the graphics. We're not quite happy with the
way you have to navigate through the screens. Their great looking, but on a
bumpy road, pretty hard to use. So we learned from the trials there. NoTec
will announce his work later due to other tasks at the moment.

Second. Some big portions of the sourcecode received an overhaul.
I'll try to list them (almost) all here:

Datastorage:
The last datastorage has been replaced by an extreme fast database engine.
This database doesn't need an extra installation, everything is still embedded.
The memory usage is way below our maximum targeted usage.
Searching and browsing has never been this fast!
The database is very compact, about 22.000 files (about 130gb), is stored in
16mb of db files!

Filescanning:
Also improved! A filescan will be done in a low priority background-thread.
A lot of work has been done to make this a smooth job. The files are immediately
available in the music-library after reading their ID3 tags. Scanning the massive
amount of files will continue after a system shutdown.
Scanning-speeds differ due to a lot of factors. Mostly disk I/O and cpu.
On my AMD X2-5200, over a 100mbit network drive, it will process about 15 mp3's
per second. On the tested CarPC, a 800mhz machine, it processed almost 2 per second.

Core:
The core got a more functional and fine-tuned file-caching mechanism now.
All loaded graphics, including albumcovers, will profit from this. The mechanism
automatically purges files from the cache to keep the memory usage under
control. Ofcourse a lot of improvements are done in the core. F.i.: we applied
external profilers to optimize the code. The result is that we're very happy with
the runtime speed of the application.
Memory usage is restricted, we don't want to cache _every_ cover loaded from disk.
The cache-system will monitor memory usage and the time since last request.
The skinfiles stay cached though. This keeps the application, including a loaded database,
below 64mb of memory.

Scripting:
The scripting language has, once again, been extended with a tenfold of commands.
Everything from radio-control to screen-control, music-control to configuration-control
is available. This means there will be a built-in configuration screen!

GPS:
Work has been done on reading a GPS device. It can be accessed by script,
and basic screen-controls have been developed to display the data.

Screen-controls:
A lot of different controls are being developed during skin-designing.
Think of buttons, switch-buttons, slider and spinner controls, etc.
Also a dial to display, fi, the speed from the GPS, or a compas to display the direction.
Additional controls will be developed when nescessary of course.

Power:
CarMa has also been optimized for different power-schema's. All types of Windows
shutdown events are supported. Hibernate, suspend and sleep. CarMa automatically
stops the used devices and will restart them after powerup.

Music:
The multiple music-player support has been replaced for a fixed solution for now.
CarMa will use Winamp 2.6+ for playing music. This also allows the use of the EQ and
other plugins as a by-effect.

Radio:
We support an FM-Radio module native now! The Silabs USB FM-Radio dongle, to be precise.
In near future, an API will become available to develop other types of radios.
For now, it only supports the Silabs module. It does, however, it supports it almost 100%,
feature-wise. Including RDS, presets (using the channel-name from RDS for the title), etc.
The radio can be muted while playing music, that way, you still receive the RDS messages.

Resource (CPU/memory) usage:
A very important part of the application. I tried to monitor the earlier mentioned CarPC
during usage. Thanks to all the optimizations, the cpu-load didn't go above 5% and 64mb
of used memory. And most of those %'s are due to Winamp, loading a file from disk.
I have to be fair, this monitoring was without filescanning in the background. But even then,
I suspect it won't climb much above 50% cpu-load.
CarMa is targeted to low-end hardware and still keep snappy response. But on modern systems,
it will use the available features of dual/quad core cpu's, more memory, etc.


So, it took a while to post an update, but we're getting pretty close to a beta now.
We still have to implement some screen-controls, make a new skin and some other stuff,
but it is almost ready for the world to run/test!

I hope you guys can wait a little bit longer.


Thanks for reading!
The CarMa Team