On Tue, Apr 17, 2012 at 10:16:01PM +0200, Pavel Hofman wrote:
Mark, I have always viewed alsa drivers as split to two parts
- the "PC world" where mostly individual often amateur developers
post patches improving support of the hardware they own.
- the ASoC world of embedded solutions, where mostly vendors
contribute patches for the hardware they produce. All ASoC posts are
That's really not a good split - while audio seems to be one of the few areas where embedded vendors are in the forefront of contributing code for their own parts there's a fair amount of hobbyist work in the embedded space too. The first example that springs to mind is the Kirkwood support which has never had any involvement at all from Marvell. Even where people are employed to work on the code they're often not working for the device vendor but rather for some other company who happens to be using the device.
Even the until recently highly active intel-hda section does not use any of the ASoC infrastructure. If you read the ASoC documentation
It wouldn't be appropriate for HDA to use ASoC, the hardware has a rather different model for how it's constructed - the main thing being that obviously there's only one control interface for all devices and you're supposed to be able to write a generic HDA driver which works on any system using HDA.
http://alsa-project.org/main/index.php/ASoC, it would not occur to me I should be using asoc codecs infrastructure for ice1724 card.
If you feel there's something that could be improved about the wiki please contribute to it. Though that said as far as I'm aware the ALSA wiki is about as actively maintained as the bug tracker which we still haven't managed to get shut down. All the content I've ever had any cause to look at is links to off site documentation, most of which are now broken as they're to pre-breakin kernel.org, and most of what's there is extremely old.
Working hard on series of patches and being met with cold attitude as for not adhering to ASoC standards (quoting the alsa-project.org:
It's really the fact that it's not using ASoC, it's the fact that patch here is adding a driver for a device which already has an in-tree driver; that alone should be a very big warning sign. Ending up with two totally separate drivers for a single device is never a good idea, if only from a duplication of work point of view.
I'd at least expect the presence of the existing driver to have prompted a question along the lines of "I can't figure out how I'm supposed to use this driver here, what am I missing?", or something in the changelog indicating that this issue had been considered and that the duplication is a sensible solution for whatever reason.
If you want these independent contributors to start using the kernel infrastructure common in the ASoC "tree", please tell them clearly on the alsa-project.org website, at best directly at http://alsa-project.org/main/index.php/Developer_Zone
Again, if you feel the documentation needs to be improved please contribute to the documentation. I honestly can't see where I'd put any information so that people would usefully find it, but then like I say that's largely because it doesn't look like the wiki gets much use so it'd put me off looking in the first place. If you're saying people actively use the wiki then probably you've got a better idea of where they're looking in there.
I can understand the very active ASoC subproject is defining current standards for the rest of alsa tree but please tell the currently valid rules to all the developers.
Like I say the major issue here is further back at the point where we're ending up with two drivers for one bit of hardware. That's not something to do with knowing about ASoC, it's more general good practice.