[Sound-open-firmware] Mixer doubts

[Pierre-Louis Bossart]

On 7/23/18 6:38 AM, Seppo Ingalsuo wrote:
> 
> 
> On 17.07.2018 16:02, Pierre-Louis Bossart wrote:
>> On 7/17/18 4:45 AM, Liam Girdwood wrote:
>>> On Tue, 2018-07-17 at 08:45 +0200, slawomir.blauciak at linux.intel.com 
>>> wrote:
>>>>
>>>> More specifically:
>>>>                dest[i] = (val[0] >> (num_sources >> 1));
>>>>                dest[i + 1] = (val[1] >> (num_sources >> 1));
>>>>
>>>> Going back in the history of the file I found it was supposed to be an
>>>> average.
>>>> However, it will only be an average if num_sources is power of 2, 
>>>> because
>>>> otherwise such bitwise operations will yield different results from 
>>>> what I
>>>> take should be an optimized way for division.
>>>>
>>>> For example, suppose we have 2 cases:
>>>> • We have 2 sources, thus num_sources >> 1 will equal 1, valid right 
>>>> bitshift,
>>>> same as division by the number of sources, which is 2
>>>> • We have 3 sources, thus num_sources >> 1 will equal 1 once again, 
>>>> no longer
>>>> valid, because it will yield the same result as division by 2, 
>>>> instead of 3.
>>>>
>>>> There’s one more “problem”, by averaging the samples like that we 
>>>> will end up
>>>> with quieter output for when we have 1 source completely silent. Is 
>>>> that
>>>> intentional?
>>>>
>>>> Whether it’s all deliberate or not, or simply whether I 
>>>> misunderstood the
>>>> code, I hope you can help me clear this up.
>>>>
>>>
>>> The intention is we have a generic optimised version that is easy to 
>>> vectorize
>>> for 2,4,8 channels (on any architecture). We will need to have a 
>>> separate
>>> generic mixer for 1,3,5,6 etc.
>>>
>>> We should also have architecture specific mixing too like we have for 
>>> xtensa
>>> HiFi3 volume.
>>
>> I also don't agree with this right shift. It's well intended and aimed 
>> at avoiding saturations as you add more sources into the mix, but I 
>> don't think it should be done this way. In general, the only solutions 
>> that work well are:
>> 1. make sure an attenuation is applied prior to the mix (i.e. don't 
>> compensate for saturations in the mix)
>> 2. implement a soft limiter as part of the mixer
>>
>> The #1 always win in practice for customer devices due to its 
>> simplicity. #2 is typical for pro-audio stuff.
> 
> Yep, I proposed earlier this also but it was postponed. We should make 
> sure the mixer uses saturating add operation and set mixer gain to 0 dB 
> for all inputs. It's too tricky for system gains planning to have hidden 
> gain enhancements (and the issue with non 2^N inputs number). We have 
> already #1 enabled if the topology is setup to ensure no signal clipping 
> in mixing.
> 
> The #2 with soft limiter as a separate component is in future plans too.
> 
> There's also third option to scale the pipelines to have some margin 
> above 0 dB level (e.g. 24 dB) and have soft limiter or saturation only 
> as last processing component in the pipelines. Though it works only with 
> fixed point 32 bit and float pipelines where audio quality is not harmed 
> significantly due to the extra room for the signal.

So there's no one in favor of keeping the existing solution so let's 
remove this right-shift for now, and refine better plans with a soft 
limiter for later.