Repository navigation
Volume component signal overflow with extreme levels #416
Description
There's mild crackling noise coming from volume component if volume levels are at maximum and incoming signal has very high levels (has to peak at max sample values). This is very "pathological" use case but might actually happen, I was getting this with pcm ripped from CD and running through sox conversion to 48kHz (which clipped couple of very high level samples). Also able to get it with a sine sweep maxed to 0dB. From recorded pcm you can see that there are couple of very sharp transitions from positive to negative -> overflow.
Activity
mengdonglin commentedon Sep 30, 2018
@juimonen Could you add the labels for the platform and branch on which you observe the bug? Thanks!
juimonen commentedon Sep 30, 2018
I saw this with up2 and master branch. However I think this will manifest in all configurations, but I have not tested all of them. It could be a certain "version" of the volume processing function (like some 24 bit to 32 bit) but I could not find/fix it yet because trace went berserk...
lgirdwood commentedon Oct 1, 2018
@singalsu any thoughts on this one ?
singalsu commentedon Oct 1, 2018
Yes, I've heard this noise too. There's rattle with highest volume and it goes away with next lower step. The volume mode in the test pipeline is 32->24. I need to test if there's difference in gcc and/or xt-xcc compiled volume since they use a different gain algo core. We can debug this now when we got trace to work again.
singalsu commentedon Nov 1, 2018
I'll start working with debugging this. I was just able to reproduce it and confirmed that this happens with gcc build and 32->24 volume mode. It doesn't happen with 16->24 and 24->24.
singalsu commentedon Nov 2, 2018
Confirmed the bug and made a fix, PR to appear soon. I need to review other conversions for similar issue. The q_multsr_sat_32x32() function ensures proper saturation to 32 bits but if the output of volume is 24 bits the result may be still be an overflow. Need to instead calculate 32 bit result and shift right by 8 to get a properly saturated 24 bit sample.
singalsu commentedon Nov 2, 2018
The bug fix is in PR #528. The test content that triggered this is a loud Van Halen song and an EQ response that has a boost at mid frequencies. Since the issue disappeared by adjusting volume down it was clear that issue was in volume (pipeline host -> EQ -> volume -> DAI). I added a wrap check trace output code into a volume that confirmed it. With the patch applied I could no more hear the issue with the same content.
@tlauda I've also checked that the HiFi3 version of volume does not have this issue. There was need to fix only the generic C version.
mengdonglin commentedon Nov 19, 2018
@juimonen Could you help to check if this issue is fixed by PR #528 on your side? If yes, please help to close the issue. Thanks!
singalsu commentedon Nov 19, 2018
I've verified this. Closing.