[alsa-devel] [PATCH v3] ASoC: dapm - Add API call to query the widgets of valid DAPM paths.

Mark Brown broonie at opensource.wolfsonmicro.com
Tue Jul 26 16:37:34 CEST 2011


On Tue, Jul 26, 2011 at 03:26:54PM +0100, Liam Girdwood wrote:
> On Tue, 2011-07-26 at 13:41 +0200, Mark Brown wrote:

> > OK, right.  If we want to do that then a substantial proportion of the
> > existing CODEC drivers are broken - they're routinely putting in the
> > stream name they want to match against rather than adding extra text to
> > the stream to give unique names that are never used.

> They should all be OK, the stream event performs a strstr() on each
> stream widget so will match left/right etc streams based on the DAI
> stream name. 

The case I'm worried about is the case where we've got two widgets with
identical stream names - left and right AIF both call their playback
widget stream "Playback" or whatever.

> > It does feel like this ought to be looking things up by widget rather
> > than by stream, though.  Widget names are already guaranteed unique and
> > if the users do want to look things up for a single widget only it seems
> > to make sense to ask for that widget rather than ask for a stream as
> > it's not how we're currently using streams.  It feels like if we're
> > asking for a stream we should do the same substring multi-match that we
> > do when pushing events into them.

> V2 did the substring match, although now that more complex hardware is
> appearing I wonder if we should connect DAIs to widgets with the widget
> name (rather than just relying on the substring). i.e. each DAI could
> have a list of AIF widgets (most would have 1 or 2). Both methods could
> co-exist for a while with the substring method being deprecated.

Yes, there's definitely room to improve here - one thing I'd like to see
is a system for mapping individual channels in the played audio so if
for example we're playing mono data (or stereo data on a 5.1 CODEC) then
we can figure out that lots of the channels aren't actually in use and
not power them on.


More information about the Alsa-devel mailing list