=================================================================== RCS file: /cvsrepo/anoncvs/cvs/www/Attic/audio-port.html,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- www/Attic/audio-port.html 2002/06/18 01:44:05 1.7 +++ www/Attic/audio-port.html 2003/03/06 13:51:31 1.8 @@ -1,3 +1,5 @@ + - +

Audio applications tend to be hard to port, as this is a domain where interfaces are not standardized at all, though approaches don't vary much between operating systems. +

+

Using ossaudio

-

Using ossaudio

- The ossaudio emulation is possibly the simplest way, but it won't always work, and it is not such a great idea usually. -

Using existing NetBSD or FreeBSD code

+

Using existing NetBSD or FreeBSD code

Since we share part of the audio interface with NetBSD and FreeBSD, starting from a NetBSD port is reasonable. Be aware that some files changed places, and that some entries in sys/audioio.h @@ -56,8 +58,8 @@ work on only one type of machine. Some changes are bound to be necessary, though. Read through the next part. -

Writing OpenBSD code

-

Hardware independence

+

Writing OpenBSD code

+

Hardware independence

YOU SHOULDN'T ASSUME ANYTHING ABOUT THE AUDIO HARDWARE USED. @@ -66,6 +68,7 @@ field against 8 or 16 bits, and assumes unsigned or signed samples based on soundblaster behavior. You should check the sample type explicitly, and code according to that. Simple example: + 

     AUDIO_INIT_INFO(&a_info);
     a_info.play.encoding = AUDIO_ENCODING_SLINEAR;
@@ -96,10 +99,10 @@
     /* now don't forget to check what sampling frequency you actually got */
-

+

This is about the smallest code fragment that will deal with most issues. -

16 bit formats and endianess

+

16 bit formats and endianess

In normal usage, you just ask for an encoding type (e.g., AUDIO_ENCODING_SLINEAR, and you retrieve an encoding with endianess (e.g., AUDIO_ENCODING_SLINEAR_LE). @@ -120,7 +123,7 @@ playing a sound sample which happens to be in your sound card native format. -

Audio quality

+

Audio quality

Hardware may have some weird limitations, such as being unable to get over 22050 Hz in stereo, but up to 44100 in mono. In such cases, you @@ -175,7 +178,7 @@ a volume scaling option.

-

Audio performance

+

Audio performance

Low-end applications usually don't have much to worry about. Keep in mind that some of us do use OpenBSD on low-end 68030, and that if a @@ -191,6 +194,7 @@

For high performance audio applications, such as mpegI-layer3, some points should be taken into account: +

-

A model you may have to follow to get optimal results is to first compile a small test program that enquires about the specific audio @@ -225,7 +228,7 @@ hardware, provided it makes a difference.

-

Real time or synchronized

+

Real time or synchronized

Considering that OpenBSD is not real time, you may still wish to write audio applications that are mostly real time, for instance games. In @@ -247,7 +250,7 @@ some lag between what the audio reports, what's currently playing, and the time it takes for XWindow to display something.

-

Contributing code back

+

Contributing code back

In the case of audio applications, working with the original program's author is very important. If his code does only work with soundblaster cards for instance, there is a good chance he will have to cope with @@ -257,17 +260,17 @@

If you don't sent your comments to him by then, your work will have been useless.

- +

It may also be that the author has already noticed whatever problems you are currently dealing with, and is addressing them in his current development tree. If the patches you are writing amount to more than a handful of lines, cooperation is almost certainly a very good idea. +

-
Porting - www@openbsd.org -
$OpenBSD: audio-port.html,v 1.7 2002/06/18 01:44:05 jsyn Exp $ + www@openbsd.org +
$OpenBSD: audio-port.html,v 1.8 2003/03/06 13:51:31 naddy Exp $