[Sound-open-firmware] Mixer doubts

[Seppo Ingalsuo]

On 23.07.2018 16:56, Pierre-Louis Bossart wrote:
> 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.

OK, I will make a pull request!

Thanks,
Seppo


> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware