• 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.

• 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.

• A simple wrapper for the standard ALSA jack detection interface. This helps makes jacks a bit easier to use in a multi-component system, providing a framework for using multiple jack detection methods on a single jack (eg, for both headphone and microphone) and automatic integration with DAPM, allowing output paths to be powered up only when a jack is present. See sound/soc/soc-jack.c.
• A new SND_SOC_DAPM_PIN_SWITCH helper for machines exposing control of DAPM pins to user applications.
• More conversion of ASoC CODEC drivers to use the new device model integrated driver registration methods.
• TI DaVinci support now works in mainline, no out of tree patches are required for the DMA code.

plus a selection of new drivers and enhancements to existing drivers..

As with any substantial change in the power sequencing there is a risk that there may have been some performance regressions on some systems – my biggest concern is that some thing were being helped by the delays introduced by the repeated register writes and may require special handling to fix. My hope is that this won’t happen if anything it should fix some problems by ensuring that both left and right channels of stereo paths get powered up together without wide testing that’s hard to guarantee. Any testing that you can do on your systems would be greatly appreciated.

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