[alsa-devel] [PATCH 2/4] ASoC: compress: Clarify the intent of current compressed ops handling

[Charles Keepax]

On Thu, May 03, 2018 at 09:57:14PM +0530, Vinod Koul wrote:
> On Thu, Apr 26, 2018 at 05:30:05PM +0100, Charles Keepax wrote:
> > It is proposed that the model adopted for compressed component
> > support currently should be that multiple components are supported
> > on a compressed DAI but that they must provide a unified set of
> > capabilities. So for example having multiple components involved in
> > the decode is fine but the core will not presently attempt to make
> > smart decisions like offloading MP3 to this component and AAC another.
> 
> Well this is supposed to be entirely a userspace call, we just present
> devices with capabilities and the usespace decides... Btw capabilities are
> supposed to be dynamic.

My intention was to not suggest otherwise. The only point I
was really making is that if there are multiple components on
the link the core won't make attempt to amalgamate output from
those components, but we will inform all components of activity
on the DAI.

> Looking at the code again now, I realized that we are treating compress like
> PCM. It makes little sense to me to have multiple components for a
> compressed device, does that model on your systems..?

So that was very much my initial reaction as well [1], and
certainly for our devices it only really makes sense to have a
single component handle the compressed ops. Hence why I initially
started with basically just returning the first component with
compressed ops.

That said however, thinking about it more I do think there are
pretty reasonable systems that have multiple components on a
compressed DAI. For example I could imagine a system where you
have a DSP on both the AP and CODEC ends of the DAI link and
they split the decode doing some work on each. In that case
one would want calls like open and set_params to go to both
components.

As you say separate decode engines probably belong on separate
DAIs and that kinda is what led me to the current series. It
should implement enough to enable basic multi-component use-cases
but makes it more clear that we are not supporting multiplexing
multiple offloads onto a single DAI at the moment.

Thanks,
Charles

[1] https://patchwork.kernel.org/patch/10182603/