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

[Vinod Koul]

On 04-05-18, 12:59, Charles Keepax wrote:
> 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.

Am not sure if we can split the decode into multiple DSPs like
this :) Yes one can do processing and one can decode if both have
the capability but I don't forsee that being split, so not sure
if we need it!!!

> 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/

-- 
~Vinod