Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Offer an optional longer filter with better performance. #189

Open
astewart-xmos opened this issue Jun 5, 2023 · 1 comment
Open

Offer an optional longer filter with better performance. #189

astewart-xmos opened this issue Jun 5, 2023 · 1 comment
Labels
type:enhancement New feature or request type:investigation Needs investigation to categorize

Comments

@astewart-xmos
Copy link

@Allan-xmos has identified that we can further improve our audio performance by using longer or more complicated filters for decimation. For example, using a 125-tap second stage filter instead of a 65, or using a 3 stage filter design.

The risk in making such a filter the default filter is that it may substantially increase MIPS or memory usage, breaking existing applications that have been tuned to make full use of MIPS and memory. Making the longer filter opt-in eliminates that risk.

Because there are several possible filter structures we could use for this, some exploratory work is also necessary to determine the trade-offs in terms of audio performance parameters, MIPS and memory.

NOTE: Nothing currently prevents lib_mic_array users from using their own longer filter within the current 2-stage decimator structure -- it just requires a bit more work than using the default coefficients. Other custom filter structures can also be implemented by users without any need to change the mic array library but require writing a bit of C++.

@astewart-xmos astewart-xmos added type:enhancement New feature or request type:investigation Needs investigation to categorize labels Jun 5, 2023
@Allan-xmos
Copy link
Contributor

A comparison of different filter structures:

  MIPS Memory (bytes)
Current 25.6 1280
Large 2S 28.672 2048
Large 3S 27.024 1484
Small 3S 25.808 1212
Tiny 2S 12.8 1152

Estimation of unoptimised MIPS = (rate*taps/decimation) for different filter topologies
Memory estimated as 4 bytes per tap

More details for each structure below:

Current

  Rate Taps Decimation MIPS Memory per mic
Stage 1 3072000 256 32 24.576 1024
Stage 2 96000 64 6 1.024 256
Stage 3 - - - - 0
      TOTAL 25.6 1280

Notes: OK performance, early rolloff and aliases

Large 2 stage

  Rate Taps Decimation MIPS Memory per mic
Stage 1 3072000 256 32 24.576 1024
Stage 2 96000 256 6 4.096 1024
Stage 3 - - - 0 0
      TOTAL 28.672 2048

Notes: Good performance

Large 3 stage

  Rate Taps Decimation MIPS Memory per mic
Stage 1 3072000 256 32 24.576 1024
Stage 2 96000 19 2 0.912 76
Stage 3 48000 96 3 1.536 384
      TOTAL 27.024 1484

Notes: Good performance, 3rd stage reduces MIPS and memory

Small 3 Stage

  Rate Taps Decimation MIPS Memory per mic
Stage 1 3072000 256 32 24.576 1024
Stage 2 96000 15 2 0.72 60
Stage 3 48000 32 3 0.512 128
      TOTAL 25.808 1212

Notes: OK performance, early rolloff and aliases

Tiny 2 Stage

  Rate Taps Decimation MIPS Memory per mic
Stage 1 1536000 256 32 12.288 1024
Stage 2 48000 32 3 0.512 128
Stage 3 - - - 0 0
      TOTAL 12.8 1152

Notes: OK performance, early rolloff and aliases, 3dB higher noise floor due to lower PDM rate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:enhancement New feature or request type:investigation Needs investigation to categorize
Projects
None yet
Development

No branches or pull requests

2 participants