Free aio software for linux

aio-xmms is an output plugin for XMMS which produces output for use with the libAIO library.

Todo: AIO plugin is a todo plugin for Aero AIO.

Usage:

- Install the plugin via the Aero-AIO config dialog.

Aero AIO: RSS News Feed is a plugin for Aero AIO. Aero AIO: RSS News Feed its based on slashdot karamba.

Plugins for Aero-AIO contains amaroK and notes plugins for Aero-AIO.
Plugins are from Kaisermart @ http://www.kde-look.org/content/show.php?content=31321 Credits to him plz!
I just optimized this two for the AIO 0.8e version by optimizing the code and making *.aiz files for an easier installation. (Because I had some trouble with his original files...) Hope they can help you!
If you have some tipps and tricks for improving (in particular) the amarok-audio-plugin please let me know! And if someone knows something about using click and drag of the audio slider bar or clicknHold for buttons...mail me plz! thx...
Install Notes:
- Download
- Unzip
- And then use the AIO Configuration utility for installing the plugins.

Aero AIO: cpu/mem plugin mod is a mod of the cpu/memory plugin for aero aio. The hardware information is gathered via backends. You can easily write a python backend for your hardware.
Look at the files cpumemv2_backend.py, cpumemv2_default.py and cpumemv2_i8k.py to learn how to write backends.
Main features:
- default backend that supports CPU temeratures via /proc/acpi/thermal_zone and hard disk temperatures via hddtemp. You can start hddtemp by (as root)
- hddtemp -d /dev/hda
- Replace hda with the hard disk you want monitored.
- ibmacpi backend (for IBM laptops). Thanks to Frank Fiene. Supports CPU, GPU, hdd, fan and pci data, via the ibm acpi kernel module. Boy those IBM laptops have a lot of sensors!
- i8k backend (for Dell laptops). Supports cpu temp and fan speeds via the i8k kernel module.
- The backends are cascaded. The code automatically looks through all backends for support of each feature. the final feature set is the union of all backends
- If an update temporarily fails (this tends to happen with hddtemp), it is indicated on the theme by the : in front of the sensor name becoming an _

aeroclock is based on "aeroG-inspired-digiclock" but resized to match "dbKalendar" (with aero theme) to make a matched set with "Aero AIO".

Audio Input-Output Library (libaio) is meant to solve the problem of differing digital audio platforms once and for all.

JACK is unnecessarily complex for most applications, and while libaos support for file output is cool, it limits what the API can do and is therefore inadequate for any kind of real time application.

libaio provides a clean application interface and a simple compile-time driver switching decision, yielding a lightweight way to use the local sound hardware without having to care what it is.

Libaios first sparkle was when I, Hod McWuff (alias, of course), found myself trying to debug ALSA implementations for libao and madplay, and another audio-related project Id been working on. That project needed multiplatform audio support of its own, with latency management, which libao lacked.

It also seemed that libao shouldnt have been trying to be both a hardware abstraction *AND* an output abstraction, and also that it seemed more intuitive as an output (live vs file) abstraction.

Enter libaio. All it does is abstract the local sound hardware platform, to present a clean, uniform interface to playing and capturing digital audio, with facilities for basic latency management. It was written from scratch around its developing ALSA driver, from many many reference sources including libao and Robert Leslies excellent madplay MP3 decoder, and of course the ALSA documentation and examples.

Libaios distinction comes from its build-time decisionmaking. It only compiles and links the best driver available for the given platform. Therefore, selecting and loading a driver no longer applies; and well it shouldnt, theres never more than one correct choice anyway.

Libaio is not intended to replace libao; rather it is intended to supplement it. The key argument is, why would anyone EVER have more than one running sound platform type on any single machine? Sure, they might have ESD or ARTS, but they more resemble file output than a live device. Theres also the OSS emulation in ALSA, but given a good ALSA driver, whod use OSS?

Then theres the fact that applications have to tell libao what "plugin" to use, and all the drivers in libao have different parameters. That means the application has to know more than it should about what it shouldnt have to see. The app shouldnt have to say more than "give me the local device for playback with *** format" or something to that effect, and start writing.

Finally, plugins for stuff like proprietary file formats, ESD et al, but there shouldnt be any need for more than one of (ALSA|OSS|SUN|WIN32|MACOSX ) on any given distribution. Therefore, binary distribution of a compiled-in driver is possible, even preferred.

It is proposed that all of the hardware drivers in libao, and madplay, and several other places, be reviewed and ported to libaio. Then, they can be removed from those packages in favor of an AIO interface.

Installation:

## building
./configure
make


## installing (as root)
make install