Aplay resampler

[borine]

This is my attempt to address the topics previously discussed in PR #459

The libsamplerate resampler causes high CPU usage. Its not so bad on x86_64, but really very high on armhf. I have not tried with arm64. Having said that, I have tested on an old pi zero W (32bit armv6) with the "SINC_FASTEST" converter and got very stable audio with accurate delay reporting watching a 4 hour video stream. top showed bluealsa-aplay consuming 28% of the (single core) CPU but the pi continued to run smoothly. So anyway this is left as an option and not included in the build by default.

[codecov]

Codecov Report

Attention: Patch coverage is 29.23077% with 184 lines in your changes missing coverage. Please review.

Project coverage is 69.85%. Comparing base (f0f9427) to head (2f16da6).

Files with missing lines	Patch %	Lines
utils/aplay/resampler.c	2.43%	120 Missing ⚠️
utils/aplay/aplay.c	48.19%	43 Missing ⚠️
utils/aplay/alsa-pcm.c	65.85%	14 Missing ⚠️
utils/aplay/resampler.h	0.00%	4 Missing ⚠️
utils/aplay/alsa-pcm.h	0.00%	2 Missing ⚠️
utils/aplay/delay-report.c	83.33%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #750      +/-   ##
==========================================
- Coverage   70.54%   69.85%   -0.69%     
==========================================
  Files          99      101       +2     
  Lines       16181    16400     +219     
  Branches     2527     2570      +43     
==========================================
+ Hits        11415    11457      +42     
- Misses       4647     4824     +177     
  Partials      119      119              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[borine]

removing all accumulated delay values will cause delay report to be ~0

yes, not good from the client view. The same is also true of the reset after an ALSA underrun. When I put those lines in I was thinking only of the resampler, needing some way to indicate that the delay report needed time to settle on a new average before using to calculate a rate adjustment. I agree that clients will benefit by removing the reset() calls, and the resampler management needs a bit more work.

[arkq]

I've rebased the resampler on top of master. However, I'm not sure whether I have not broken anything along the way... Also, I have not reviewed changes yet, it's only a bling rebase attempt. Over the weekend I will try to do some preliminary review of all these changes.