Status of audio on 3.3 kernel for ARM

[Daniel Drake]

Hi,

I spent most of Friday and another 4 hours on Saturday working on the
arm-3.3 audio issue. The problem is that only silence is produced.

>From what I can see the core of the problem is that the "DAPM"
(dynamic audio power management) code is passed a representation of
the widgets (amps, muxes, mixers) inside the audio codec. Then, when
playing a sound, it has to find a route from the input (DAC, in the
case of playback) to output (e.g. speakers), and then power up all the
components on that route.

When playing sound normally, it appears not to find a meaningful route
and leaves all of the widgets powered down. This can be seen with cat
/sys/devices/platform/soc-audio/*5631/dapm_widget (and you can compare
to 3.0 where various things do get powered up during playback).

If you make some tweaks to the mixer controls (even ones that should
have no net effect) you can sometimes poke DAPM into looking for a
route again and finding one and powering up the right components, e.g.
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-May/051686.htm

To solve this, I first tried to understand and debug the DAPM logic.
This is tedious and time consuming, with so many widgets and routes in
our codec driver there is a lot of recursion and after a few hours I
still couldn't make any sense of it.

I then tried to simplify our driver, removing practically all routes
and widgets at the DAPM level and just pre-configuring registers to
have the right components for audio playback through the speakers
working. No luck there either - couldn't get any audible output.
I think this is the right approach though - first remove all the
dynamic stuff just to have playback working, then re-add the widgets
and routes one-by-one (based on the codec datasheet which has a nice
logic diagram) with repeated testing to make sure nothing gets broken.

This seems like a hard issue.

Daniel