[alsa-devel] [PATCH 4/6] compress: add API header and driver header files

[Nallasellan, Singaravelan]

> > > + * @decoded: Frames decoded by DSP
> > > + * @rendered: Frames rendered by DSP into a mixer or an audio
> > > + output
> > > + * @sampling_rate: sampling rate of audio  */ struct
> > snd_compr_tstamp {
> > > +	size_t copied_bytes;
> > > +	size_t copied_total;
> > > +	size_t decoded;
> > > +	size_t rendered;
> > > +	__u32 sampling_rate;
> >
> > Is it possible to track the rendering sampling rate in the driver
> > itself?
> 
> What do you mean? This is a streaming API, the actual rendering rate will depend on
> what endpoint you play on.

I guess the driver should know the sampling rate of the endpoint. If only the DSP knows 
about the endpoint sampling rate, this will make sense.

> 
> > > +struct snd_compr_caps {
> > > +	__u32 num_codecs;
> > > +	__u32 min_fragment_size;
> > > +	__u32 max_fragment_size;
> > > +	__u32 min_fragments;
> > > +	__u32 max_fragments;
> > > +	__u32 codecs[MAX_NUM_CODECS];
> > > +	__u32 reserved[11];
> >
> > Can we add number of compress streams supported in DSP?
> 
> You are confusing number of formats supported with number of streams supported.
> The latter is exposed through the actual devices supported.

No, DSP may be able to support only so many simultaneous streams at any point of time. 
Yet, DSP can support any number of formats. Though the device entry may be created for
each compressed stream, how will the user space programs get the number of compressed streams supported?