On Wed, 2016-02-17 at 19:46 +0530, arun at accosted.net wrote: > From: Arun Raghavan <git at arunraghavan.net> > > This exposes the range of configurations the library actually supports > (8, 16, 32 and 48 kHz). That doesn't seem to explain all changes in the code. I'll analyze all the variables: play_ss.format is handled as before, fixed to s16le. play_ss.rate was earlier set to out_ss.rate, now it's set to one of the four possible rates based on the initial rec_ss.rate value. play_ss.channels and play_map were earlier set to out_map, now they are unchanged. rec_ss.format is handled as before, fixed to s16le. rec_ss.rate was earlier set to out_ss.rate, now it's set to one of the four possible rates based on the initial rec_ss.rate value. rec_ss.channels and rec_map were earlier set to out_map, now they are unchanged. out_ss.format is handled as before, fixed to s16le. out_ss.rate was earlier kept unchanged, now it's set to one of the four possible rates based on the initial rec_ss.rate value. out_ss.channels and out_map were earlier kept unchanged, now they are set to the original value of rec_map. In summary: no changes in sample format configuration, rate is based on the original rec_ss instead of the original out_ss and limited to the four possible rates (earlier there was no such limitation, so is the commit message wrong saying "relax restrictions"?), channels are based on rec_map instead of out_map. There is and there was no limitation on the channel count - but should there be? I don't think the processing can handle very many channels, at least before switching to deinterleaved processing. --Â Tanu
