• Support for registering machine drivers as first class devices rather than using the soc-audio device. Support for the soc-audio device will be removed at some point in the future.
• Support for ordering widget power changes within widget types, helping with large CODECs and multi-stage amplifiers.
• Support for waiting for multiple slow events to complete during DAPM sequences, making it easier to handle things like DC offset correction on multiple outputs.
• CPU support for Intel Medfield and nVidia Tegra2.
• CODEC support for Cirrus CS4271, Freescale SGTL5000, Maxim MAX8950, National Semiconductors LM4857, TI SN95031 and Wolfson WM8991
• Machine support for Intel Medfield MID reference platforms, nVidia Harmony, and Visstrim M10.

• Enhancements to multi-component from Jarkko Nikula allowing multiple devices of the same type to be included in one system (and handling other overlaps between devices) and support cross device DAPM.
• Support from Dimitris Papastamos for compressing the register cache in memory using either an rbtree or LZO, giving substantial memory savings on CODECs with large register maps, especially those that are sparse. This is especially beneficial to modern devices with integrated DSPs. This can be enabled by machine drivers, though CODECs can also provide defaults.
• Addition of trace points around DAPM and register I/O operation, allowing very low overhead logging without interfering with the main system log, useful for collecting verbose diagnostics without interfering with system operation and for always enabled flight recorder style tracking for intermittent problems. I blogged about ASoC trace points in more detail at the time.
• Restructuring of the Samsung CPU support from Jassi Brar, including a number of really good usability improvements. This supports features of more modern CPUs such as the ability to run two audio streams to a single I2S port and includes a number of API simplifications which should also make developing drivers for Samsung systems much easier.
• New CODEC drivers for ALC5621/2/3, WM8737, WM8770 and WM8958.
• Machine support for HP iPAQ H1940, HP t5325 thin clients and OpenRC Ultimate.

There’s a bunch of existing documentation out there for the trace subsystem, including some in the kernel under Documentation/trace, which I won’t repeat here. The ASoC events are grouped together under ‘asoc’. The raw log can be viewed by looking at the file tracing/trace in debugfs. Here’s a sample output from starting playback of an MP3 on a Samsung SMDK6410 reference system using WM8580, a high performance six channel CODEC with a very simple software interface:

mplayer-1673  [000]   183.920000: snd_soc_dapm_start: card=SMDK-I2S
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=Rear val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=Center+Sub val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=Front val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT3R val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT3L val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT2R val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT2L val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT1R val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=VOUT1L val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=DAC3 val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=DAC2 val=1
mplayer-1673  [000]   183.920000: snd_soc_dapm_widget_power: widget=DAC1 val=1
mplayer-1673  [000]   183.920000: snd_soc_bias_level_start: card=SMDK-I2S val=2
mplayer-1673  [000]   183.920000: snd_soc_bias_level_done: card=SMDK-I2S val=2
mplayer-1673  [000]   183.920000: snd_soc_reg_read: codec=wm8580-codec.0-001b.27 reg=32 val=1e
mplayer-1673  [000]   183.920000: snd_soc_reg_write: codec=wm8580-codec.0-001b.27 reg=32 val=2
mplayer-1673  [000]   183.920000: snd_soc_bias_level_start: card=SMDK-I2S val=3
mplayer-1673  [000]   183.920000: snd_soc_bias_level_done: card=SMDK-I2S val=3
mplayer-1673  [000]   183.920000: snd_soc_dapm_done: card=SMDK-I2S
mplayer-1673  [000]   183.920000: snd_soc_reg_read: codec=wm8580-codec.0-001b.27 reg=13 val=10
mplayer-1673  [000]   183.920000: snd_soc_reg_write: codec=wm8580-codec.0-001b.27 reg=13 val=0

Each line represents a trace event, showing the process that initiated the event, the CPU it ran on and the time it was recorded at together with event-specific details. On this system the time is reported with 10ms accuracy and the CODEC is very simple so the timing information is not terribly informative, but more accurate timers can be really helpful in analysing what’s going on with more complex CODECs. The set of events available will change over time, the key ones currently present in the kernel are:

• snd_soc_dapm_start and snd_soc_dapm_done: These events show the start and stop of the DAPM algorithms, showing the time spent on power management decisions.
• snd_soc_dapm_widget_power events are generated for each of the widgets which DAPM has determined needs to change state. The ‘val=1′ means that all these widgets are being powered up, val=0 would show power down.
• snd_soc_reg_write events show values written to registers.
• snd_soc_reg_read events show values read from registers – these reads may be done from the register cache, or may be from the hardware.
• snd_soc_dapm_widget_event_start and snd_soc_dapm_widget_event_done show the time spent in per-widget event callbacks.

The set of events traced will change as the subsystem develops and as people gain more experience with using the trace API.

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.

Still, a long way to go before user space can start to rely on knowing if things are plugged in or not.

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.