Writing a fully-featured, clear and flexible ALSA libaudio for Gingerbread: TinyALSA-Audio
Written by Paul Kocialkowski 2 commentsAs I am porting Replicant, our fully free Android derivate, to the new Goldelico GTA04, I had to deal with ALSA user-space integration in Gingerbread. So let's take a quick look about it:
On Gingebread (and previous versions), user-space audio is done via the libaudio library. The Android framework will basically interact with AudioFlinger that is the component in charge of loading that libaudio library and dealing with it (that's frameworks/base/services/audioflinger/AudioFlinger.cpp
).
So libaudio is basically the place where PCM read/write and mixer stuff happens. As we started looking into the various existing ALSA libaudio, my fellow Replicant developer GNUtoo told me about TinyHAL, a clean and flexible audio module that does ALSA and routing from XML configuration files. Too bad, TinyHAL was designed for Ice Cream Sandwich, and the Audio API changed in ICS (basically, it is now a module, like the ones for gps, sensors, lights, etc). So I couldn't use it as-is, but there were various concepts I hoped I would be able to reuse, like the XML routing config or the use of the TinyALSA lib, that is very clean, simple to use and handles ioctl-level ALSA stuff.
In the end, I decided to write my own libaudio, using both TinyALSA and XML config files, that I called TinyALSA-Audio. Audio output and Mixer was quite straightforward and worked quickly. AudioFlinger basically opens the AudioStreamOut at 44100Hz, 2 chans, S16_LE format (signed 16bits, little endian), which works fine with the audio hardware, a TWL4030 Codec here, that didn't complain at all.
Next step was about audio input and recording. At first sight, I thought it would be as easy as audio output, that is just setting the controls, opening the device via TinyALSA, sending the config following what AudioFlinger asks and just read the data. So I basically wrote code that was that simple, but it failed while setting the config: cannot set hw params: Invalid argument
was the error. As I didn't see what could possibly be wrong about the params, I decided to take a look at how tinycap, the capture utility that comes with TinyALSA handles things. It actually sets the params at 44100Hz, 2 chans, S16_LE, and recording works then. When I tried to force the params to what AudioFlinger asks, that is 8000Hz, 1 chan, S16_LE, I got the very same error as on my libaudio: cannot set hw params: Invalid argument
.
So what was it all about? Does the CODEC only records at 44100Hz, 2 chans? I tried with zygote stopped, and then 8000Hz mono worked. I also checked in the kernel code: the TWL4030 CODEC is supposed to work at 8000Hz mono as well. So I deducted that when the output device is opened, the input device will only work at the same config (rate, chans). What a bummer! AudioFlinger asks for 8000Hz mono, not 44100hz stereo, though that's all I can get when output is opened (which is always the case when zygote is running).
Thanks to the AOSP, there are various others libaudio that I could use to learn things. First thing to know was if that "issue" was specific to TWL4030 or common to all ALSA CODECS. So I did the same test (with tinycap) on the Nexus S and Galaxy S, and the result was that both couldn't record at any other rate/chans that the ones set when opening output. Galaxy Nexus audio module confirmed that too. So what is the solution here? Obviously, it consists in finding a way to return 8000Hz mono data to AudioFlinger while reading 44100Hz stereo data: that's resampling.
Galaxy S and Nexus S libaudio all handled resampling by internal algorithms, which seemed a pain to use and adapt on my libaudio. The solution finally came from the Galaxy Nexus audio module. And I really want to send a big Thank-You to the people who wrote it. First of all, it uses the very same TinyALSA as my libaudio uses. Second thing is that it doesn't embed complicated algorithms for resampling but uses the new Android 4 framework for resampling, that wasn't so hard to understand. behind that engine is the libspeexresampler lib, that is part of speex code. So all I had to do was to backport that Android 4 resampling code, enable to build of libspeexresampler in gingerbread and make use of all that in my lib.
Though, wait a second, when reading AudioFlinger code, it all seemed to indicate that AudioFlinger embeds its own resampling engine, so that when the lbiaudio reports different parameters, it handles resampling to what it wants (mostly 8000hz mono). So I tried to make use of that, in vain. I couldn't figure out why it didn't work, it just didn't. I read the AudioFlinger code several times, made sure the resampler was enabled and all, but in the end, the produced audio was just garbage, so I just gave up on using AudioFlinfer's resampler. After all, if all the AOSP libaudio do not make use of it, there might be a reason. So the thing appears to be totally messed-up and nobody cares enough to fix it but rather implement resampling in the libaudio itself. Not a very good thing for me, I would have preferred to leave resampling to the upper layer, but anyway, I had Galaxy Nexus code that could be adapted to my lib. So that's basically what I did: backporting the Android 4 resampler code to my libaudio, making use of it and using ICS external/speex
repo. In the end of this misadventure and with some fine tuning, it all worked.
That's pretty much the end of the story, now I have my TinyALSA-Audio lib that handles input/output routing via mixer audio output and audio input as well, to various rates. Here are some links:
- TinyALSA-Audio source code in my personal git repo: tinyalsa-audio.git
- TinyALSA-Audio source code in Replicant repo: hardware_tinyalsa-audio
- An exemple configuration file (for GTA04): tinyalsa-audio.xml