On Thursday 05 June 2008 09:22:06 am Haavard Skinnemoen wrote:
quoted text
> Geoffrey Wossum <geoffrey@pager.net> wrote:
> > For anyone that's interested, there's patches to add ALSA System-on-Chip
> > sound platform drivers for the AVR32 being discussed on the alsa-devel
> > mailing list right now.
>
> Hmm. For something that depends on a metric shitload of middle layers,
> it is surprisingly large...

Partly because the code attempts to handle every contingency an application 
might throw at (different sample rates, formats, clocking options, etc.).  
Partly because it also has some concern for power management.


quoted text
> I have to admit I don't understand the current sound situation at all.
> With this driver, we now have:

To paraphrase Andy Tanenbaum, the great thing about standards is there's so 
many to choose from.


quoted text
>   * An OSS driver for the AP7000 Audio Bitstream DAC
OSS <shudder>


quoted text
>   * A "regular" ALSA driver for the AC97C (not based on ASoC)
I don't have an AC97 CODEC.


quoted text
>   * An i2s driver for the AT73C213 chip using the SSC controller and SPI
Strongly coupled to the AT73C213, not the chip I'm using, although it did 
provide a good example of working code.  This is where I figured out I needed 
to use big endian.


quoted text
>   * Some sort of "AT32 PCM" layer which apparently can only be used
>     with the SSC controller
This IS sort of confusing.  It's really more of a generic SSC / PDC driver 
than a "PCM layer".  Its existence is largely an artifact of it being in the 
AT91 ASoC platform code, which I "ported" to get the AT32 platform code.  Its 
existence in the AT91 platform driver is an artifact of the AT91 driver being 
based on the PXA platform driver.  In other words, I'm not really the one to 
explain the design rationale behind it.

 
quoted text
>   * The above two being essentially identical to similar drivers for
>     AT91
Yes, I didn't particularly like making the AT32 code almost exactly like the 
AT91 code, and most of the differences are due to changes in some kernel APIs 
rather than the peripherals really being different (BTW, the changes in the 
AT32 are an improvement!).  But I needed an AT32 layer quickly, and I don't 
have any AT91 hardware, so I couldn't really go mucking about in the AT91 
code since I wouldn't be able to test it.  I don't feel especially bad, 
though, since at91_mci.c and atmel-mci.c commit essentially the same sin.


quoted text
> Can someone please help me out here? In particular, what is ASoC and
> why should I want to use it?

Number 1 reason (for me):  The only driver for my CODEC (WM8510) was an ASoC 
driver.  Using sound system other than ASoC would require porting / rewriting 
this driver.  Since an AT91 ASoC platform driver already existed, and would 
be virtually the same as the AT32 platform driver, this was the best choice 
for getting sound quickly.  So this essentially boils down to code reuse.  
And if we switch CODEC's for some reason, it's less work.

Another highly compelling reason: power consumption.  Only powers up parts of 
the audio pathway that are currently needed.

For more reasons:  http://alsa-project.org/main/index.php/ASoC
Legal notice: I received no compensation for this endosement :)

---
Geoffrey
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/