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 30.59701% with 186 lines in your changes missing coverage. Please review.

Project coverage is 69.87%. Comparing base (f0f9427) to head (8670572).

Files with missing lines	Patch %	Lines
utils/aplay/resampler.c	2.43%	120 Missing ⚠️
utils/aplay/aplay.c	48.27%	45 Missing ⚠️
utils/aplay/alsa-pcm.c	68.88%	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.87%   -0.68%     
==========================================
  Files          99      101       +2     
  Lines       16181    16404     +223     
  Branches     2527     2572      +45     
==========================================
+ Hits        11415    11462      +47     
- Misses       4647     4823     +176     
  Partials      119      119              

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

[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.

[borine]

I found a bug in the already-merged alsa-pcm code: the written frames are counted twice when calculating the delay. commit 082f1bb fixes that, and I recommend it be merged before the resampler code.

commit 8670572 edaf670 is also worth considering for immediate merge as it reduces the CPU load (slightly) and helps keep the delay report more stable.

There is at least one bug in the resampler (softvol muting may use the wrong sample format), and I hope to have a commit for that ready later today. Other than that the resampler is now looking good in my testing with iphone and bluealsa sources.

[arkq]

I've squashed all the commits (to simplify review outside of github) and rebased it on top of master.

[borine]

Testing with a bigger range of source applications has shown that there is (at least) a couple of issues with this as it stands:

1. Inserting silence to prevent underrun can result in large delays if the source has regular breaks in the stream. I'm experimenting with using snd_pcm_drain() to stop the alsa device cleanly when there are no frames to play, and so far this is giving a better listener experience than padding the buffer with silence.
2. The resampler can become unstable when the source stream is unsteady, resulting in very wild swings in the rate adjustment. I'm experimenting with enforcing limits on the magnitude of the adjustment to control this.

I hope to have some updates next week if these new ideas prove useful.

Incidentally, one of my test sources is my multi-client branch of bluealsa with chromium, and this has proven to be particularly troublesome. I was planning to submit that as a PR soon, but it will have to wait longer as clearly there is (yet another) problem which must be solved first.