Cross Platform Audio(sound) Libraries ..

Cross Platform Audio(sound) libraries:

1. PortAudio
2. RtAudio
3. JUCE
4. libsoundio
5. SDL
6. OpenSL
7. OpenMAX

PortAudio - PortAudio is a free, cross-platform, open-source, audio I/O library.  It lets you write simple audio programs in 'C' or C++ that will compile and run on many platforms including Windows, Macintosh OS X, and Unix (OSS/ALSA). It is intended to promote the exchange of audio software between developers on different platforms. Many applications use PortAudio for Audio I/O.

RtAudio - RtAudio is a set of C++ classes that provide a common API (Application Programming Interface) for realtime audio input/output across Linux, Macintosh OS-X and Windows operating systems. RtAudio significantly simplifies the process of interacting with computer audio hardware.

JUCE - JUCE (Jules' Utility Class Extensions) is an all-encompassing C++ framework for developing cross-platform software. It contains pretty much everything you're likely to need to create most applications, and is particularly well-suited for building highly-customised GUIs, and for handling graphics and sound. JUCE officially supports Windows, Mac OS X, Linux, iOS, and Android.

libsoundio - libsoundio is a lightweight abstraction over various sound drivers. It provides a well-documented API that operates consistently regardless of the sound driver it connects to. It performs no buffering or processing on your behalf; instead exposing the raw power of the underlying backend. libsoundio is appropriate for games, music players, digital audio workstations, and various utilities.

SDL - Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D. It is used by video playback software, emulators, and popular games including Valve's award winning catalog and many Humble Bundle games. SDL officially supports Windows, Mac OS X, Linux, iOS, and Android. Support for other platforms may be found in the source code.

Festival - library(&Edinburgh Speech Tools library) is a C++ Text to Voice generation library.

OpenMAX DL - OpenMAX DL (Development Layer) APIs contains a comprehensive set of audio, video and imaging functions that can be implemented and optimized on new CPUs, hardware engines, and DSPs and then used for a wide range of accelerated codec functionality such as MPEG-4, H.264, MP3, AAC and JPEG.

OpenSL ES - A royalty-free, cross-platform, hardware-accelerated audio API tuned for embedded systems. It provides a standardized, high-performance, low-latency method to access audio functionality for developers of native applications on embedded mobile multimedia devices, enabling straightforward cross-platform deployment of hardware and software audio capabilities, reducing implementation effort, and promoting the market for advanced audio.

OpenMAX vs OpenSL

OpenSL and OpenMAX are intended for slightly different uses, but have an overlap of functionality. OpenSL is intended for complex audio systems while OpenMAX is intended for general multi-media systems. Either can be used separately, or if needed both can be used - in the overlapping area the functionality is the same (even though the function calls are distinct). From the OpenSL ES and OpenMAX Al specifications this is shown by the following figure: 

64-bit data models

The 64-bit architecture has the following advantages:

• A 64-bit application can directly access 4 exabytes( 1 exabyte = 10¹⁸ bytes (or)  2⁶⁰ bytes ) of virtual memory, and the Intel Itanium processor provides a contiguous linear address space.
• 64-bit Linux allows for file sizes up to 4 exabytes, a very significant advantage to servers accessing large databases.

32-bit and 64-bit data models

	ILP32	LP64	LLP64	ILP64
char	8	8	8	8
short	16	16	16	16
int	32	32	32	64
long	32	64	32	64
long long	64	64	64	64
pointer	32	64	64	64

Note:
The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true.

The difference among the three 64-bit models (LP64, LLP64, and ILP64) lies in the non-pointer data types. When the width of one or more of the C data types changes from one model to another, applications may be affected in various ways. These effects fall into two main categories:

• Size of data objects. The compilers align data types on a natural boundary; in other words, 32-bit data types are aligned on a 32-bit boundary on 64-bit systems, and 64-bit data types are aligned on a 64-bit boundary on 64-bit systems. This means that the size of data objects such as a structure or a union will be different on 32-bit and 64-bit systems.
• Size of fundamental data types. Common assumptions about the relationships between the fundamental data types may no longer be valid in a 64-bit data model. Applications that depend on those relationships will fail when compiled on a 64-bit platform. For example, the assumption sizeof (int) = sizeof (long) = sizeof (pointer) is valid for the ILP32 data model, but not valid for others.

Sample Operating Systems:

Microsoft Win64 (X64/IA64) => LLP64

Most Unix and Unix-like systems (Solaris, Linux, HP-UX Itanium , etc.) => LP64

Fujitsu-owned HAL Computer Systems => ILP64

Endianism

Endianism refers to the way in which data is stored, and defines how bytes are addressed in integral and floating point data types.

Little-endian means that the least significant byte is stored at the lowest memory address and the most significant byte is stored at the highest memory address.

Big-endian means that the most significant byte is stored at the lowest memory address and the least significant byte is stored at the highest memory address.

Table 3 shows a sample layout of a 64-bit long integer.

Table 3. Layout of a 64-bit long int

	Low address							High address
Little endian	Byte 0	Byte 1	Byte 2	Byte 3	Byte 4	Byte 5	Byte 6	Byte 7
Big endian	Byte 7	Byte 6	Byte 5	Byte 4	Byte 3	Byte 2	Byte 1	Byte 0

For example, the 32-bit word 0x12345678 will be laid out on a big endian machine as follows:

Table 4. 0x12345678 on a big-endian system

Memory offset	0	1	2	3
Memory content	0x12	0x34	0x56	0x78

If we view 0x12345678 as two half words, 0x1234 and 0x5678, we would see the following in a big endian machine:

Table 5. 0x12345678 as two half words on a big-endian system

Memory offset	0	2
Memory content	0x1234	0x5678

However, on a little endian machine, the word 0x12345678 will be laid out as follows:

Table 6. 0x12345678 on a little-endian system

Memory offset	0	1	2	3
Memory content	0x78	0x56	0x34	0x12

Similarly, the two half-words 0x1234 and 0x5678 would look like the following:

Table 7. 0x12345678 as two half words on a little-endian system

Memory offset	0	2
Memory content	0x5678	0x1234

The following example illustrates the difference in byte order between big endian and little endian machines.

The C program below will print out "Big endian" when compiled and run on a big endian machine, and "Little endian" when compiled and run on a little endian machine.

Listing 2. Big endian vs. little endian

#include main () { int i = 0x12345678; if (*(char *)&i == 0x12) printf ("Big endian\n"); else if (*(char *)&i == 0x78) printf ("Little endian\n"); }

ref:

Porting Linux Applications to 64bit - http://www.ibm.com/developerworks/library/l-port64/index.html

Migrating to Solaris 64-bit: 32-bit Applications and Data Model - http://developers.sun.com/solaris/articles/solarisupgrade/64bit/Convert.html

Converting 32-bit Applications Into 64-bit Applications: Things to Consider - http://developers.sun.com/solaris/articles/ILP32toLP64Issues.html

64bit Windows Operating System Overview

The performance benefits seen from the x64 OS have been substantial. Because of the larger virtual memory space available to the processes. There are 232 possible combinations that a 32-bit address can take (meaning 4GB worth of addressable space). On the x86 operating system, half of that is allocated for the kernel, and the other half is given to user mode processes. Since the addressing spaces of the user mode processes are independent of each other, each process can reference up to 2GB of memory. With a 64-bit addressing space, there is a possibility of 264 unique address combinations (16 exabytes). The x64 OS currently uses 43 bits for addressing, giving the kernel 8TB of addressable memory, and leaving the other 8TB for user mode processes.

WOW64 Layer

WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run on 64-bit Windows.WOW64 launches and runs 32-bit applications seamlessly. The system isolates 32-bit applications from 64-bit applications, which includes preventing file and registry collisions. Console, GUI, and service applications are supported. However, 32-bit processes cannot load 64-bit DLLs, and 64-bit processes cannot load 32-bit DLLs.

Restrictions of the WOW64 subsystem
The WOW64 subsystem does not support the following programs:
• Programs that are compiled for 16-bit operating systems
• Kernel-mode programs that are compiled for 32-bit operating systems

16-bit programs
The x64-based versions of Windows Server 2003 and of Windows XP Professional x64 Edition do not support 16-bit programs or 16-bit program components. The software emulation that is required to run 16-bit programs on the x64-based version of Windows Server 2003 or of Windows XP Professional x64 Edition would significantly decrease the performance of those programs.

If a 32-bit program that requires 16-bit components tries to run a 16-bit file or component, the 32-bit program will log an error message in the System log. The operating system will then let the 32-bit program handle the error.

If there are any 32bit Applications that make use of 16bit binaries (.exe/.dll) and these 16bit binaries (.exe/.dll) need to be copied to the Win64 machine during Migration Process then these applications may stop working on the Win64 machine.

32-bit drivers
The x64-based versions of Windows Server 2003 and of Windows XP Professional x64 Edition do not support 32-bit drivers. All hardware device drivers and program drivers must be compiled specifically for the x64-based version of Windows Server 2003 and of Windows XP Professional x64 Edition.

If a 32-bit program tries to register a 32-bit driver for automatic startup on a computer that is running an x64-based version of Windows Server 2003 or of Windows XP Professional x64 Edition, the bootstrap loader on the computer recognizes that the 32-bit driver is not supported. The x64-based version of Windows Server 2003 or of Windows XP Professional x64 Edition does not start the 32-bit driver, but does start the other registered drivers.

If there are any 64bit Applications that make use of 32/16bit Device Drivers and these 16bit binaries (.exe/.dll) need to be copied to the Win64 machine during migration Process then these applications may stop working on the Win64 machine.

File System Redirection
When a Windows API function to detect the operating system on which you are running, the File System Redirection function maps your 32- or 64-bit files to the appropriate system directory. Any time a 32-bit process attempts to access c:\windows\system32 the WoW64 layer redirects it into c:\windows\syswow64 which contains all of the 32-bit Windows binaries. This prevents a 32-bit process from trying to load a 64-bit binary. Any scripts or tools running in a 32-bit process that is referencing this directory will be automatically redirected to the syswow64 directory.

A new C:\Program Files directory is introduced with 64-bit Windows. The familiar Program Files directory is now reserved for native 64-bit applications. Your 32-bit applications are directed to the new C:\Program Files (x86) directory.

Registry Redirection
Any 32-bit process trying to read or write to HKEY_LOCAL_MACHINE\Software\ gets redirected to HKEY_LOCAL_MACHINE\Software\Wow6432Node\. This allows separate configurations to be maintained for 32-bit and 64-bit processes. Any custom settings or keys set in this node may need to exist in both keys, as 32-bit processes will be redirected to this new branch.

Links
http://msdn.microsoft.com/msdnmag/issues/06/05/x64/default.aspx http://www.acucorp.com/company/newsletter/newsletter_featured/featured_6.php http://msdn.microsoft.com/chats/transcripts/windows/windows_110904b.aspx

C/C++ : Guidelines - Porting to 64bit Operating Systems

Guidelines to remember while porting C/C++ Applications to 64-bit mode

• Data Truncation
• Avoid assigning longs to ints
• Avoid Storing Pointers in ints
• Avoid Truncating Function Return Values
• Use Appropriate Print Specifiers

• Data Type Promotion
• Avoid Arithmetic between Signed and Unsigned Numbers

• Pointers
• Avoid Pointer Arithmetic between longs and ints
• Avoid Casting Pointers to ints or ints to Pointers
• Avoid Storing Pointers in ints
• Avoid Truncating Function Return Values

• Structures
• Avoid Using Unnamed and Unqualified Bit Fields
• Avoid Passing Invalid Structure References

• Hardcoded Constants
• Avoid Using Literals and Masks that Assume 32 bits
• Avoid Hardcoding Size of Data Types
• Avoid Hardcoding Bit Shift Values
• Avoid Hardcoding Constants with malloc(), memory(3), string(3)

Ref:
Migrating to 64-Bit Environments - http://www.informit.com/guides/printerfriendly.asp?g=cplusplus&seqNum=201

Porting to a 64-bit Platform - http://www.devx.com/Intel/Article/27237/2217?pf=true

HP-UX 64-bit Porting Concepts - http://docs.hp.com/en/5966-9844/ch03.html

HP-UX 64-bit Porting and Transition Guide: HP 9000 Computers - http://docs.hp.com/en/5966-9887/

Target 32- and 64-bit Platforms Together with a Few Simple Datatype Changes -http://www.devx.com/cplus/Article/27510/1954?pf=true