List of ALSA Issues

Here's my list of issues I found with the current ALSA API while developing PA:

Mixer

There's no way to detect whether a snd_smixer element is implemented in software or not. Thus writing an application that uses the PCM device hw: (or front:, surround51:, ...) and the smixer/mixer interfaces at the same time with sensible behaviour is impossible. Because for those devices software volume adjustments don't take place, and thus the controls we find are useless.
There is no way to find the right mixer device for a PCM device. There is no way to find which one is the right mixer track to use to control input and output PCM volume, other then guessing by the name.
ctl, hctl, mixer, smixer. Come on!
It is not possible to enumerate the ctl/hctl elements that make up a smixer element.
It is possible to query the dB range of a smixer element. And it is possible to query and set the current dB level. However, it is not possible to have a dB value converted to an integer level or vice versa, without touching the actual setting. i.e. a question like "What is the integer level 0 dB corresponds to?" can not be answered by ALSA. Which happens to be a serious limitation. Update: This seems fixed now
the dB scale is is almost useless. dB is a relative scale and ALSA didn't define what the reference level is. All mixer controls on all sound drivers use different reference levels. Hence the dB scale is not any more useful than that they are pretty to look at and make you feel like oh-i-am-such-a-guru-i-look-at-dB-levels.
Naming hinting apparently cannot be used to enumerate mixer devices.
It's not possible to know the inter-relation of ctls (except single switch/track couple), and the relation with actual devices: internal mic, loudspeaker, laptop red jack, rear green jack, usb headset mike (or at least, this is quite tricky, or not well exposed)
Multichannel mixer controls are not exposed properly: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-October/011830.html
The dB data exposed is sometimes bogus. e.g. on many cheaper USB devices alsa says the volume range is from one dB value to the same dB value.

PCM

Timestamps such as state->tstmp are in CLOCK_REALTIME, there's no way to use CLOCK_MONOTONIC instead, which makes them kind of impractical to use. Update: Since 1.0.16 they are supposed to be CLOCK_MONOTONIC, but actually they are still useless. Update 2: There is now snd_pcm_hw_params_is_monotonic() in alsa-lib HG. Update 3: Unfortunately that call doesn't work: http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/014839.html
There is no way to detect in advance (i.e. when setting up the hw parameters) if rewind() would ever work on a device, thus making this functionality pretty much useless. Update: There is now sndpcm_hw_params_can_forward in alsa-lib HG. I am happy!
There's no way to disable implicit sample type, channel map conversion in plughw:. You either get a fancy-we-do-it-all device (plughw:), or a completely raw device (hw:), there's no way to selectively disable/enable any of the additional features of plughw, except for resampling. That includes the previously mentioned sample type conversion or channel map, and softvol. Update: This is fixed now, the SND_PCM_NOAUTO_xxx flags in 1.0.16 offer exactly what I need.
There's no way to query the active channel map for a device
Device enumeration is completely broken and useless, and not useful for hotplug
There's no way to detect whether spdif: can be used at the same time as any of the ther other PCM devices (i.e. front: or suchlike) of the same card or if they are exclusive. There is no API to query if opening a certain PCM device with a specific configuration will make a related PCM device return EBUSY. (i.e. there seem to be some devices where opening a 6ch output stream will cause opening the device for capturing to return EBUSY)
There's no way to disable the buffer management of ALSA, it insists on deciding what a full or an empty buffer is. It is not possible to be notified about interrupts, independantly of the buffer fill level via poll().
The is no device string for mono-only devices in style of "front:", "surround50:" and suchlike.
There is no way to disable fragment interrupts for a device entirely, which would be useful in timer-based scheduling. Update:' This apparently has been fixed at least partially, there is now snd_pcm_sw_params_set_period_event().
There is no API to query the granularity of snd_pcm_delay()
The devices with an explicit channel mapping (i.e. "surround41:", ...) cannot be used for 10ch and 12ch sound cards. There is also no definition for surround91: and surround111.
The buffering model has major issues. Another iteration of the story. Different drivers implement completely different logic for snd_pcm_delay(), e.g. for USB hw snd_pcm_delay() is way off what should really be returned. "Fast" buffer emptying after playback start is not communicated to the application.
An application which wants to use surround sound has no chance to do so in any sensible way unless it goes directly to the hw devices "surround41:0" and so on. This kicks virtual drivers like PA out of the game however. This boils down to: no practical surround sound for ioplug based plugins. For ioplug based plugins only stereo and mono can be implemented sensibly.
Currently there is no point in opening "default" in anything but 1ch or 2ch, since otherwise the channel mapping is unknown.
Async PCM is evil. Signals suck.
The maximum buffer size on HDA is a too small for real good glitch-free: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-June/008550.html
snd_pcm_rewind() breaks playback and returns nonsense, unless the naked audio device (hw) is accessed. (i.e. all plugins such as softvol break snd_pcm_rewind()) (Update: This has been fixed in alsa-lib git shortly after the 1.0.17 release)
The "multi" plugin (and a couple of other drivers as well) sends POLLOUT but then snd_pcm_update_avail() returns 0: http://mailman.alsa-project.org/pipermail/alsa-devel/2008-October/011842.html
I want something that tells my how long it is possible to sleep before an underrun happens. http://mailman.alsa-project.org/pipermail/alsa-devel/2009-January/014020.html
There is no way to fetch the timestamp, the delay, and the avail value that belong together. http://mailman.alsa-project.org/pipermail/alsa-devel/2009-February/014839.html

ioplug

ioplug is in a really bad state.
There is no way to reflect back XRUN states to the application

General

Documentation is really bad. Misses documentation of what terms like "trigger" mean and suchlike. However, terms like that are used extensively in the documentation. The examples from the documentation lack any comments.
The API is way too verbose and large. There are too many functions that seem to be obsolete today, or that are completely redundant, or should only be used internally, and not be exported, or even appear in the documentation.
The API is way overengineered. Even if the four abstraction levels of the mixer (ctl, hctl, mixer, smixer) might make some technical sense, there is no point whatsoever to export them all in the user interface. This applies to other stuff in the API as well.
The library spams to stderr. On my mono usb soundcard (a webcam) opening the PCM device via "front:" (which rightfully fails) produces a lot of noise on stderr, which apparently cannot be disabled. And there are lots of similar cases. Update: There's snd_lib_error_set_handler() which can be used to stop this.
Nobody cares about the ALSA BTS. Bugs are posted there and forgotten.

Individual drivers

(semi-off-topic) For a list of various ALSA drivers with PA-related bugs, see Broken Sound Drivers.