The legacy AWE 6 product line, including AWECore for embedded/bare metal targets, and AWELib for rich OS targets (Linux, Android, Windows), has been in use for almost 4 years. AWE Core 8 is now replacing AWE Core 6, and AWE Core OS is replacing AWELib.
But AWE 6 works well for me, why should I switch?
The main goal of the updates in AWE 8 is to make integrations of the AWE Core easier on any customer platform. To this end, improvements were made to the product in the following ways:
Smaller, more intuitive API
AWE6 API functions spread across multiple, large header files, making it difficult to know which functions to use. AWE8 has a single API header, “AWECore.h”
Consistent naming conventions.
All AWE8 API’s start with ‘awe_’, and functions are further categorized into subgroups. For example, audio related functions begin with ‘awe_audio’.
Multi-core applications easier to implement
Removed the CoreDescriptor/callback function for packet processing and routing packets. In AWE 8, BSP author receives core packets and then has full freedom to handle them as needed
Doxygen generated .pdf and .html, fully navigable, and with more example apps
Built in support for common audio data types and built in channel matching
More available modules
AWELib -> AWE Core OS
In addition to the above, AWE Core OS also provides the following improvements over AWELib:
Easier and better multi-rate processing capabilities (auto-multithreading on SMP systems)
Simpler and more configurable instance initialization
Integrated tuning interface for any TCP/IP enabled device
Built in input and output audio recording to .wav files
More and better sample applications, including a real-time audio sample app using Alsa
Improved configurability of included modules
C library, not C++, so more portable
Single function to load encrypted/unencrypted layouts