[alsa-devel] ASoC and a codec that can't be controlled
timur at freescale.com
Tue May 29 21:02:14 CEST 2007
Liam Girdwood wrote:
> Yes, although my feeling is that a codec "driver" would still be needed
> to define the capabilities of your codec within the audio subsystem.
Why is it the codec driver that calls snd_soc_new_pcms()? Shouldn't the PCM driver be
Looking in snd_soc_new_pcms() itself, I see this:
codec->card = snd_card_new(idx, xid, codec->owner, 0);
Here we create a new "sound card", and we assign it to the
I guess I just don't understand why the codec driver is acting like the "master" driver of
ASOC. IMHO, the codec driver should be doing two things:
1) Specifying the capabilities of the codec hardware itself, without any assumption that
these capabilities dictate the capabilities of the system as a whole (e.g. the codec
shouldn't assume that the system supports every sampling rate that the codec does).
2) Providing APIs for controlling the codec.
ASOC and the machine driver should then work in tandem to decide which driver will do what
and which capabilities are *actually* supported. *Something* needs to look at the entire
system and say to each device, "Well, yes, I know about this little feature of yours, but
we're just not going to support that today."
Linux Kernel Developer @ Freescale
More information about the Alsa-devel