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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
