Bandwidth is a very important factor when dealing with audio. A useful way to optimize an audio player is to see it as a decompressor. The longer you can keep with the compressed data, the better usually. Very short loops that do very little processing are usually a bad idea. It is generally much better to combine all processing into one loop.
Some formats do incur more overhead than others.
If your application is already able to output all kinds of weird formats, and reasonably optimized for that, try to use a native format at all costs. On the other hand, the emulation code present in the audio device can be assumed to be reasonably optimal, so don't replace it with quickly hacked up code. 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 hardware available, then proceed to configure your program so that it deals optimally with this hardware. You may reasonably expect people who want good audio performance to recompile your port when they change hardware, provided it makes a difference. 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.