[alsa-devel] [RFC PATCH 0/4] Initial prototype of DAPM sample rate domains

[Pierre-Louis Bossart]

On 10/11/18 11:28 AM, Charles Keepax wrote:
> Here is a first pass at adding dapm sample rate domain
> support. Things are still pretty rough in quite a few places and
> I expect some major refactoring before they are ready to merge,
> but things are far enough along for people to look at the approach
> I am taking to the problem. And should provide enough for discussion
> at the mini-conference, although hopefully I will get some more done
> next week as well.
Interesting, too bad I couldn't be in Edinburgh this year.
>
> The basic high level summary is two new concepts are added to
> ASoC, one being a sample rate domain and the other being a domain
> group. The domain groups represent widgets that are limited by
> hardware restrictions to always run at the same sample rate as each
> other. Sample rate domains represent a slot on a device for a sample
> rate. Both of these are currently limited to be within the scope of
> a single component.  The core will track which groups are connected
> together, then as a group is powered up it will be allocated a domain
> based on the other groups it is connected to. Domain groups are
> implemented as a new type of DAPM widget and the domains themselves
> are a new thing which devices add through their component drivers.
>
> As we have previously discussed my intention would be that we also
> add bridges between domains although I haven't started work on that
> yet. The current code is limited to within a single component and
> I think that the bridges will allow better support for propagating
> rates between components as well as obviously for SRCs. Currently
> the SRCs on wm5110 are just being handled as points where the
> domain groups don't connect to another peer.  This allows them to
> function but doesn't accurately convey things like the limitations
> which input rates support which output rates on the ISRC.

My feedback would be: why limit the domains to sample rate definition? 
we can also have additional criteria such as number of channels, channel 
maps and bit depth - maybe also audio/non-audio for compressed stuff. 
It'd be interesting to start with a non-scalar descriptor from day1. To 
some extent we'd also want something similar to .info definitions, with 
domains defined with masks to allow for flexibility in the conversions 
and easier bridge implementations. e.g. it'd be interesting to have a 
domain definition supporting more than one sampling frequency (8, 16, 
48kHz) with the bridge doing the relevant conversion to adapt to the 
connected domain (fixed 48kHz DAI for example)

Thanks for starting the discussion!

-Pierre

>
> Thanks,
> Charles
>
> Charles Keepax (4):
>    ASoC: dapm: Add support for hw_free on CODEC to CODEC links
>    ASoC: dapm: Add support for a rate domain widget
>    ASoC: domain: Add sample rate domain support
>    ASoC: arizona: Add rate domain support
>
>   include/sound/soc-dapm.h   |  14 ++
>   include/sound/soc-domain.h |  98 +++++++++++
>   include/sound/soc.h        |   8 +
>   sound/soc/Makefile         |   2 +-
>   sound/soc/codecs/arizona.c | 255 ++++++++++++++++++++++------
>   sound/soc/codecs/arizona.h |  76 ++++++++-
>   sound/soc/codecs/wm5110.c  | 414 ++++++++++++++++++++++++++++++++++-----------
>   sound/soc/soc-core.c       |   8 +
>   sound/soc/soc-dapm.c       |  57 ++++++-
>   sound/soc/soc-domain.c     | 412 ++++++++++++++++++++++++++++++++++++++++++++
>   10 files changed, 1183 insertions(+), 161 deletions(-)
>   create mode 100644 include/sound/soc-domain.h
>   create mode 100644 sound/soc/soc-domain.c
>