• Support for turning CODEC biases off completely when idle, providing power savings for modern devices with ground referenced outputs where this can be done quickly at runtime without pops and clicks.
• Support for disabling physical writes to the device in the generic cache control code, allowing devices to be completely powered off when idle while still providing their control to userspace through the standard register interfaces.
• Support for tuning the time ASoC waits before powering things down after playback has finished (in order to involve issues between tracks or similar) at runtime or from the machine driver.
• New drivers for DA7210, DB1200 I2S and AC97 controllers, i.MX3x SSI ports, OMAP4 McPDM ports, S3C64xx AC97 controller, SH SIU (Sound Interface Unit), WM2000, WM8904, WM8912, WM8955, WM8978, and WM8994

• New CODEC drivers for ADS117x, AK4671, TLV320DAC33, TPA6130A2, WM8711 and WM8727.
• Support for the PCM port on Samsung SoCs.
• Substantial improvements to DMA performance and reliability on MPC5200 and DaVinci.
• Capture support for the FSI port on SH.

• Redone power sequencing code, giving shorter power sequences which
  should reduce the effect of any artifacts that exist.
• Reporting of power management decisions via debugfs, enabling much
  easier diagnosis of path setup problems.
• Beginning of work to factor out the register access and caching code
  from the individual CODEC drivers into a shared file.  This needs to
  be rolled out over more CODEC drivers.
• New CODEC drivers for AD1836, AK4642, MAX9877, WM8523, WM8776, WM8961, WM8974 and WM8993
• New CPU support for multi-channel Blackfin SPORT, DaVinci McASP, i.MX2x SSI, and OMAP 1510 McBSP.

To help work with these buses Linux 2.6.32 will follow the clock API and allow the use of the dev_name() for the device instead. A new field dev_name has been added to struct regulator_consumer_supply which should be used instead of dev – this is now the preferred mechanism. It is a simple string and so does not depend on any other initialization.

For those backporting the relevant commit is 744ea1d0b59bf084f19559b8f199b644fbb0899c.

• DAPM supply widget, for automatically managing things like charge pumps and gateable clocks which may be used by more than one widget.
• Core support for setting up constraints for symmetric sample rates (for systems with a shared LRCLK).
• Support for a range of new CODECs: STAC9766, WM8940, WM8960, WM8988, and WM9081
• New CPU support too: MPC5200 AC97 and the I2S interface of the Stretch S6000.

Plus lots of updates and fixes to existing code, especially to the OMAP and TWL4030 drivers.

The reason ALSA does things the way it does is that the ALSA APIs that applications interact with are actually implemented by a library. This library provides a plugin based way of defining sound cards, one of the options for which is that the audio can be routed to or from some hardware, but sound can also be routed to other places like networked speakers. This architecture also allows plugins to provide signal processing – mixing is the example most people notice but things like soft volume controls (not all sound hardware provides volume control) or EQ are also possible.

This could all be implemented in kernel space but there’s some serious drawbacks in doing so. There are some substantial restrictions on what kernel space code is allowed to do, one of the most relevant being the fact that floating point instructions can’t be used. It’s harder to develop kernel code, if for no other reason than the fact that kernel code can crash the system. The main benefit that people expect from pushing things into the kernel is performance but with the facilities available in Linux there’s no real reason why performance would be better with a kernel mode implementation, kernel and user threads are both scheduled together and shared memory is available.

So why are people running into issues with PulseAudio? Obviously some of them are just bugs in PulseAudio – the much wider deployment that cones with being used as standard in distributions means much wider testing – but that’s not all of it, especially now PulseAudio has been in distributions for a while. The other major source of issues is that due to the need to adapt to the different needs of the applications that it is mixing together PulseAudio is a very demanding user of drivers. This means that switching to PulseAudio can expose bugs in the drivers, often bugs that have existed for years. There’s a natural tendency to blame PluseAudio when this happens but the fixes that are needed are in the drivers.

None of this is terribly helpful if you’ve been bitten by one of the bugs of course, but hopefully it goes some way towards explaining why this implementation has been chosen and why there have been problems.

Joss is right, though – most applications should be working with a higher level user space API than either ALSA or OSS. One of the most obvious examples of this is in the embedded space where there are often vast numbers of controls that need to be exported in order to support the complex audio routing that devices like phones can have. Most of these should only be touched very occasionally when changing use case and should therefore be hidden from normal applications where they’re at best irrelevant and at worst confuse end users. They do, however, need to be exposed by the kernel in order to allow user space the flexibility to manage the audio configuration of the system at run time.

In other kernel release news, I’m glad to see some of my other work is making people happy.