[alsa-devel] [PATCH 07/11] ASoC: tegra: Add tegra-das driver
broonie at opensource.wolfsonmicro.com
Thu Jan 6 23:13:01 CET 2011
On Thu, Jan 06, 2011 at 01:58:22PM -0800, Stephen Warren wrote:
> Mark Brown wrote:
> > On Thu, Jan 06, 2011 at 09:46:10AM -0800, Stephen Warren wrote:
> > > "allows". It'd still be nice if the default (in the absence of any
> > > alsamixer or UCM setup) was that opening e.g. hw:0,0 would allow some
> > > simple use of the audio, e.g. playback to primary output, capture from
> > > primary input, so that simple testing could be performed without having
> > Probably the only people who'd get much from this are people who are
> > using a reference system with no userspace provided, which is fairly
> People who're bringup up a board without expecting they need to know
> anything about alsa-lib would get a bit out of this:-) :-)
The trouble is they're in a recursive problem where it's pretty
difficult to know what a sane setup is for their system/
> So I guess what'd help me through this the most is knowing exactly how
> the user-space is configured; is this all stuff in /etc/asound.conf or
> some other config file? When you were talking about user-space earlier,
This is up to userspace. Some systems use asound.conf and
/usr/share/alsa/cards. Some systems have init scripts which run amixer
commands. Some systems use UCM or their own implementations of that
idea. Some systems restore an 'alsactl store' dump in an init script.
Partly it depends on how much flexibility is needed - if you've only got
one input and one output (as is very common) then things are much like
on a PC, the bigger more complicated the system the more fun things get.
> I was thinking of writing a custom application per board/machine to
> configure the system at e.g. boot time (or libraries that apps would use),
> which didn't sound appealing; maybe that's part of my misunderstanding.
I was talking about a single application that can choose multiple
configuration files using some algorithm.
> Are there any public examples for ASoC in particular that I can read in
> concert with the driver source to get the idea? I did find
> alsa-lib.git/src/conf but that seems to only cover desktop PCs, not
> ASoC drivers.
Beagleboard is the most obvious example, and pretty close to the systems
you're working on in terms of features. Not that I know off the top of
my head what exactly the various software stacks for that are doing or
where to find them.
Really there's no difference to PCs here, the userspace API is exactly
the same and anything that works on PCs should work on an embedded
system. You'll generally get more knobs to twiddle but the mechanics of
doing so are identical.
More information about the Alsa-devel