[Sound-open-firmware] Mixer doubts

[Seppo Ingalsuo]

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.

Thanks,
Seppo



>
>
>>
>> Liam
>>
>>> Thank you,
>>> Sławomir Błauciak
>>>
>>> _______________________________________________
>>> Sound-open-firmware mailing list
>>> Sound-open-firmware at alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>> _______________________________________________
>> Sound-open-firmware mailing list
>> Sound-open-firmware at alsa-project.org
>> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
>>
>
> _______________________________________________
> Sound-open-firmware mailing list
> Sound-open-firmware at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware