After doing little bit homework I popped up with XWax which is an open-source Digital Vinyl System (DVS) for Linux. It works great and believe me it’s geeky. Still it left me little bit blank because I liked to use some Dj controller to load music.  XWax doesn’t support Dj controller at least I didn’t get mine working. So back to square one.

Then I crossed Mixxx and it looked very promising but Mixxx version 1.10 left much to hope for. After a short while they released version 1.11 which was better but I noted that plenty of MP4 format audio files didn’t work (most of the my music is encoded with Vorbis and wrapped with Ogg that works great but if you buy something they tend to favour MP4).

Make long story short. I get involved with Mixxx and it have very nice community, fixed non-working FFmpeg plug in and fixed handfull of Linux specific stuff. After making FFmpeg plug in working I noticed I have solved most of my digital Dj problems. Mixxx works with Linux… check, openSUSE.. thank you for asking yes, is open source… GPLv2, Dj controllers.. long list,  Digital vinyls.. serato and traktor and have nice working skinnable interface.. check.

Only thing is that Mixxx is using Portaudio with Linux and Portaudio doesn’t play nice with Pulseaudio but I wrote patch for Portaudio and it’s currently in ‘works for me’-stage which means late Beta. If I ever got time I’ll give it a facelift, commit it to Github and generate little bit documentation and try to again get it to official Portaudio

But if you are open source Dj and like to test state-of-art version (which is light years ahead last one) of Mixxx I’ll recommend to test Mixxx version 1.12 beta. You should understand it’s Beta software and if you find bug please report it. But if you want to stick with stable Mixxx version 1.11 there is nothing wrong with that it’s also very capable application.

In openSUSE you can download it with zypper from Packman repos.

History

LibAO is developed under Xiph umbrella. Xiph is the organization who brought you Ogg/Vorbis, FLAC, Theora and currently they are hammering together next generation video codec Daala. Opus-audio codec standard is also Xiph project. LibAO rised from Xiph’s need multi-platform audio output library for Vorbis-audio codec. In this point if you don’t have any glue what I just said in last sentences I think you should take your spoon and start shovelling about Open Source audio codecs.
Becaus of the history libAO only has output mode and doesn’t use any callbacks. It doesn’t have fancy Float32 mode (as much as I understood) but that doesn’t say it’s bad thing. It works as expected you just feed bytes and after while you hear them from your speakers.

What about API

Supported outputs: Alsa, Oss, Jack, Mac OS X, Windows
License: GNU General Public license 2.0+

As said libAO API is difficult to describe since there almost ain’t NAN of it. You initialize, ask output device, put in your mode settings and start feeding data. Pulseaudio simple is almost easy as this but it’s still more difficult if you compare it to libAO. LibAO doesn’t support recording so only output and there must be a way to use another device than default but it’s not very easy to find or I was too lazy to dig it out.

So who wants to use libAO? People in hurry and don’t mind GPL-license, someone with very very tiny need of just getting audio out and people how hate bloat.

Summary: So if you hate bloat and again license doesn’t make you unhappy please use this library. Still libAO has kind of same problem that ALSA has. It’s mature, usable and ready for hardcore torturing but is it sexy? No! Is fresh? No, No! Is something that will change it API every week or hour?

After this I have to choose what to bring next. I have FFmpeg, Gstreamer and VLC in row. If you have opinion about next framework let me know.

Loki only shipped CD’s for installing your application and there wasn’t hot fixes waiting when you got CD from post or yes there where but I had to wait and wait for 200 MB blob to download for ages with my 57600 modem. All the time I thought that I’ll boot Windows for playing Castle Wolfestein. It was long before before Linux have any gaming community what so ever. There weren’t Firefox or Chrome available and Google was just starting to own our lifes.  So it was dark days of late ’90 (we had electricity thanks for asking).

Loki was founded on 1998 and  it got on bankruptcy on 2001 after IT bubble blowed. Loki changed Linux in good way. One thing that they left behind was called Simple Direct Layer (SDL1). SDL layer sits top on Xorg that makes creating games more ease. You can port your game to Windows and Mac OS X with little effort. Current version of SDL is SDL2.

Good thing about SDL is that it abstracts drawing to screen in Windows, Mac OS X and X-windows. SDL1 was all about pixel buffers but SDL2 is all about surfaces and acceleration. It support many more OSes but that’s not the what we are looking at today. So how do you playing audio out of SDL1/2?. Good thing is audio interface stayed same through conversion from SDL1 to SDL2. They only added few bugs and float point audio in SDL2.  SDL1 have recording but I didn’t manage to make it work so if anyone with more patience than me can lead me to correct path I would be happy puppy. Here is SDL Github location: https://github.com/illuusio/linux-audio-example/tree/master/sdl

Simple Direct Layer API

Supported outputs: Alsa, Oss, Pulseaudio, Mac OS X, Windows, iOS, Android
License: SDL1 GNU Lesser General Public License 2.1 and SDL2 ZLib license

SDL API is like name says very simple and it’s very popular toolkit. SDL can be found on every bigger Linux distribution out of box (at least SDL1 and SDL2 is fast spreading). SDL can be used for graphics, input and audio. SDL API is actually almost dead simple. Support for audio outputs if very good on Linux and things are like if it’s working on Linux it works on Mac OS X and Windows the same.  Playing audio was so easy that I get frustrated when I tried to make recording example. I even read the source code how it should be done and yes It doesn’t work with SDL2 that what I learner but I couldn’t get it working in SDL1 nether.
SDL audio API is fully and only callback based. You give your callback function and it just get called when SDL feels audio should be played. After that you feed the correct type output as much callback asks and then you wait another callback to feed more. Simple and very efficient.
If you compare callback system to Pulseaudio with SDL you can’t get no information what ALSA, Pulseaudio or OSS is doing. You just feed and they just get played out of speakers. If audio is that what makes your game rock then SDL could be what you want.

SDL audio for whom.

It’s for people who don’t need much or don’t have interested how audio get played. People who likes to get audio out with ease and fast. Currently SDL development is under Steam umbrella so they have some commercial interest with it. SDL1 was licensed with LGPL+2.0 and SDL2 is under Zlib license which mostly same like than MIT-license. SDL is also mostly rock solid, sanely licensed (SDL2) and used by many many Indie (The UnReal World RPG if I have to mention one Indie game that I know well) and not so Indie games. Biggest problem with whole SDL is lack of documentation. There is wiki but if there is no question you crawler through web and test everything you find along if it solves your problem. Development is also little bit slow and fixing bugs are not getting fixed in fast but if you can live with that it’s all yours!

Summary: Very simple to get audio out of speaker. Not for high-end or surround sound but mostly for games or playing videos this is excellent! Learning curve is non exist or  there is small: you got to understand C well to work with SDL. Works with IOS and Android so if you are on cross platform this can help you out.

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.