You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can
a) add the EQIIR on mic capture and keep it active
b) remove EQIIR on all paths
c) all the EQIIR on mic capture but have the default as bypassed.
The text was updated successfully, but these errors were encountered:
Option a) probably. A low frequency cutoff highpass (e.g. 40 Hz) is a good bet for all acoustical mic applications. Option c) also works, we will be able to use UCM to set up the EQ when need.
Option b) is not feasible. The IIRs have been added after reports about strong DC pulses in capture begin or with headset button presses.
ok for a), makes sense to deal with button-press and other shenanigans, and IPC4 topology will be better than IPC3 ones.
@ranj063 is this something we can do with the pipeline extension stuff or are there still some dependencies to be worked out with the topology compiler?
Describe the bug
in IPC3 products, the headset capture does not have any EQIIR processing, while the mic capture does.
In IPC4 products, the headset capture does have an EQIIR processing while the mic capture does not.
This is inconsistent and leads to confusion on capabilities, as noted in thesofproject/linux#3766
To Reproduce
use existing topologies
Reproduction Rate
100%
Expected behavior
Consistent behavior for all new IPC4 products. We are not going to fix IPC3 at this point.
Impact
user experience, specifically pop-clicks on capture start
@singalsu please chime in with recommendations.
We can
a) add the EQIIR on mic capture and keep it active
b) remove EQIIR on all paths
c) all the EQIIR on mic capture but have the default as bypassed.
The text was updated successfully, but these errors were encountered: