Open Sound System

First let’s talk about Open Sound System first before going to ALSA. After that we talk about todays topic: Pulseaudio.  I recall correct OSS was the first sound system that provided support for audio in Linux kernel. Even today it’s emulated by ALSA and you can use it as output with Pulseaudio. Real OSS still lives as Proprietary library and it’s implemented in several OS like FreeBSD.
If you look OSS as API point of view it’s very blocking because it uses heavily IOCTL-calls and because they are direct memory calls you have to wait. Only reason I can imagine why someone wants to support OSS in new application is trying to support whole UNIX family. If it’s not must then trust me you don’t want OSS. Event lack of duplex audio wasn’t biggest problem at late ’90.  I had Gravis Ultrasound and OSS support sucked a lot. ALSA wasn’t even pre-alpha and without thinking I jumped that rapidly moving wagon.

ALSA

Advanced Linux Sound Architecture is current Linux Audio API. You should use it for new applications and it has impressive set of supported audio chips. I haven’t find a single audio hardware that doesn’t work. Only problem with ALSA is that is so stable that it’s getting little bit too mature. times have change from ’90 and ALSA is starting look not fantastic like I thought about it first but just OK.
Getting your hardware working is not the complicated case with ALSA. Hard part comes whne you want set up more complicated patterns like USB audio, Bluetooth or send audio to another machine for playing.

Nowadays Every other platforms than Linux desktop had neat audio servers. There have been several attempts for Linux also ESD, KDE audio server and several others that never reached much attention. There is also JACK but it’s again little bit too hard to use and not for old morons like me. Believe I have use it for high-end stuff and I cannot recommend it more but when you just want your audio come from the speaker without routing it half an hour then Pulseaudio is just better, sorry you can hate me being old senile fart.

Pulseaudio

Supported outputs: Alsa, Oss, Jack, Mac OS X, Windows
License: GNU Lesser General Public License 2.1

So why we talked ALSA and OSS? Because Pulseaudio doesn’t handle sound cards. It expects that someone else have knowledge about what cards are in system and how to use them. Pulseaudio just provides common way to use them. But let’s start from beginning shall we? Lennart Poettering is who created Pulseaudio. His new beast Systemd is just like Pulseaudio hated from the start and dividing Linux community but making huge impact in Linux. Pulseaudio was meant to be replacement for Gnome ESD and there is compatibility layer for ESD available.  Pulseaudio works for  KDE, XFCE and others. Prove me wrong but I don’t know anyone how misses ESD! I miss KDE 2.0 Audio server Arts in sentimental moments but in my point of view ESD was horrible piece of crap. My opinion is only Android Audioflinger is more popular audio server in Linux world. Sometimes I wonder why Pulseaudio doesn’t provide Audioflinger compatibility layer? How does Pulseaudio sit top of the Linux audio stack. I try to make nice picture of it.

If you want to talk to sound card you make connection to Pulseaudio server with Pulseaudio C-library and talk to the Pulseaudio. Not direct to ALSA not direct to sound card. Pulseaudio is built upon sockets so you can access Pulseaudio from another machine or from network if you have bandwidth and play your tunes from or to other machine. Pulseaudio takes care about find out what sound cards you may have and connecting to them for example Bluetooth audio device. What is so wrong with Pulseaudio if it’s working so well? Basicly, it adds latency between application and audio coming out of speakers. Not me or not you not your mother are going to spot it but those nerdy super HIFI audio humans (Homo HIFIcus) can spot it. If you have some very bad audio chip there you notice but 99% times you are happier with Pulseaudio than without it.

Stop praising Pulseaudio and get to API

As beautiful as Pulseaudio API is it’s horrible same time! Modern slick callback based monster that just does something and at the you get audio or you can play it so feed me with bytes. I think they noticed this and made blocking Simple API. Which is very simple and easy to use. If you don’t want to use Pulseaudio Simple API then oh boy!
There is two main mode which you can use if we count Simple API out. There is normal mainloop and threaded mainloop. So if you want to control everything you choose mainloop mode. You iterate your mainloop and get events to your callbacks or you can let Pulseaudio do it with pa_mainloop_run() command. In threaded version it just runs and gives you callback as you go. Difference is that threaded loop stays away of you sight and normal blocks your application.

What kind of callbacks there is?

In Pulseaudio question is more like what doesn’t have callback. Stream is ready, check, buffer underrrun, check, something weird just happen, check. You just choose what to implement and then they appear as they happen. Then you choose do something or not.

Is there something wrong with this. No there isn’t, it works as expected. Actually it worked better than I was expecting. Learning curve for Pulseaudio is bit high because fully understanding how Pulseaudio works takes time and patience.

Summary:  Little bit weird pure C API but when correctly implemented very powerful. Widely spread in Linux world such all major distributions use it. Even it support Mac OS X and Windows it’s not really as easily portable at it sounds. It’s little bit Linux specific although BSD family is  beginning to use it. But if you need to support Linux and want to have higher level API than ALSA then this is for you but most frameworks support it so you can also leave it to them and not shovel into API.

Application

Like I said example applications are very simple. With Every library I tried to write playback and record example. If you can use blocking API interface there is blocking example also. In these Examples I use sndfile because API is super easy to use and I could test with WAV. So no troubles big bobbles approach.

Code

I won’t be posting code here it can be found on Github repository. I tried to be super clear as they are examples and added comments as needed but if you don’t get glue fault is all mine.

Portaudio

Supported outputs: Alsa, Oss, Jack, Mac OS X CoreAudio and Many Windows Audio API’s

Why do want to use something else than ALSA? If you need to support other platforms than Linux you get idea of cross platform API for audio. Portaudio is hidden gem of Linux audio libraries. It’s stable as can get. Portaudio has blocking and callback support. It has Float 32-bit Int 32-, 16- and 8-bit input/output. I tries to be very high end in every corner. Also licensing is very liberal.  For a while It’s has seen slowing development  because main developers have something else to do in life.

For me biggest no-no for me was lack of Pulseaudio support (I go so upset that I wrote Pulseaudio  hostApi for Portaudio but that is worth of another blog post). Portaudio supports Windows, Linux and Mac OS X so it’s good choice if you need same quality audio in every platform.

Biggest minus in Portaudio is there ain’t much applications using it. There is some highlights like Mixxx and Audacity. Rest of the list can be found here. Why it’s not more popular I can’t say because it’s easy to use.

Summary: Simple but powerful API for I/O which I can recommend. So go and see examples if it’s for you and documentation from official pages. Next time we get on Pulseaudio.