On Thu, Aug 15, 2013 at 6:27 PM, Mark Brown <broo...@kernel.org> wrote: >> Yes, we try not to. I do not recall the technical arguments in full, >> Daniel would, but they included very limited processing power, very >> limited memory, it didn't work when we first tried it, and a suite of >> applications that use the ALSA controls directly that we would have to >> port. > > Hrm, I suspect you'll find that either the processing power stuff is all > fixed or it's due to bugs in the DMA in the driver which will probably > get you sooner or later - worth checking out just in case, Pulse gets a > lot of stick for things that are actually driver issues, it ends up > being a really good test of the DMA implementation (some of the issues > I saw mentioned in the changelogs sound like they might've been an issue > for Pulse). Even if you don't use it it might help validate the driver > layer.
The last time we tried PulseAudio, it segfaulted on startup, and we didn't get into the diagnosis. It was years ago though, and we haven't tried since. We do want to give it another go but it has never taken a high enough priority for us to actually do it. We also agree that UCM looks like it will solve some of our problems, and we'd like to fix/use the dynamic routing in the upstream codec driver. Just need to find time to work on it. 3 of us have already spent a considerable amount of time on the routing issue with little progress :/ Manually validating the links between the components against the spec seems to be a very time consuming process and prone to human error. Maybe you have some suggestions or tools to help on that front. The issue is that upon playback, nothing is reproduced, and the dapm files in sysfs show that almost everything on the codec is powered down. Thanks Daniel _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel