Re: [RFC 2/5] compress: add compress parameter definations

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

Thanks Mark for your feedback.

> > +/* AUDIO CODECS SUPPORTED */
> > +#define MAX_NUM_CODECS 32
> > +#define MAX_NUM_CODEC_DESCRIPTORS 32
> > +#define MAX_NUM_RATES 32
> > +#define MAX_NUM_BITRATES 32
> 
> Can we avoid these limitations?  The limit on the number of CODECs in
> particular strikes me as not sufficiently high for me to be confident
> we'd never run into it.  Consider a server side telephony system...

The MAX_NUM_CODECS is actually the number of formats supported by your
firmware, it's not related to the number of streams supported in
parallel on your hardware. We could see support for 8 MP3 decoders, the
number of codecs would be 1. This was dynamic but we limited it to make
our life simpler. There's no problem to make it more flexible.
We can align the sampling rates to use the exising ALSA definitions.
The descriptors correspond to the number of variations for a given
format, we can probably restrict it to 32...

> I'd be inclined to add:
> 
> +#define SND_AUDIOCODEC_G723_1                  ((__u32) 0x0000000C)
> +#define SND_AUDIOCODEC_G729                    ((__u32) 0x0000000D)
> 
> for VoIP usage as part of the default set but obviously it doesn't
> really matter as it's trivial to add new numbers.

Yes we can add these codecs, but it's actually extremely difficult to do
any kind of hw acceleration for VoIP. G723.1 needs extra signaling for
bad/lost frames, and you may want coupling between jitter buffer
management, decoding and possibly a time-stretching solution to
compensate for timing issues or dropped frames. This is difficult to
implement if the speech encoding/decoding is done on the DSP, while the
jitter buffer management is done on the host. The data transfers based
on ringbuffers/DMAs makes it also difficult to handle frames of varying
sizes while limiting latency.
I'd rather push RTP packets down to the DSP and have the complete VoIP
stack handled there.

> Should we use the existing ALSA rate constants and whatnot for the
> sample rate here?

Yes. No issue on our side.