[dvdplayer] Use inexact seeking like omxplayer
[omxplayer] Make use of TrueHD fastpath when downmixing

The TrueHD codec actually works in 3 stages. It decodes the downmixed stereo. It then decodes the differences required to produce 5.1.
It then decodes the differences required to produce 7.1.

Many users end up downmixing this 7.1 stream back to 2.0.
Much better to tell the codec we only need the 2.0 stream. It saves about 50% of the CPU required
[omxplayer] When in dual audio mode, make one output the slave

May help audio sync between the two outputs
 truehd: add hand-scheduled ARM asm version of mlp_filter_channel.

Profiling results for overall audio decode and the mlp_filter_channel(_arm)
function in particular are as follows:

              Before          After
              Mean   StdDev   Mean   StdDev  Confidence  Change
6:2 total     380.4  22.0     370.8  17.0    87.4%       +2.6%  (insignificant)
6:2 function  60.7   7.2      36.6   8.1     100.0%      +65.8%
8:2 total     357.0  17.5     343.2  19.0    97.8%       +4.0%  (insignificant)
8:2 function  60.3   8.8      37.3   3.8     100.0%      +61.8%
6:6 total     717.2  23.2     658.4  15.7    100.0%      +8.9%
6:6 function  140.4  12.9     81.5   9.2     100.0%      +72.4%
8:8 total     981.9  16.2     896.2  24.5    100.0%      +9.6%
8:8 function  193.4  15.0     103.3  11.5    100.0%      +87.2%

Experiments with adding preload instructions to this function yielded no
useful benefit, so these have not been included.

The assembly version has also been tested with a fuzz tester to ensure that
any combinations of inputs not exercised by my available test streams still
generate mathematically identical results to the C version.
truehd: break out part of rematrix_channels into platform-specific callback.

Verified with profiling that this doesn't have a measurable effect upon
overall performance.
truehd: add hand-scheduled ARM asm version of ff_mlp_rematrix_channel.

Profiling results for overall audio decode and the rematrix_channels function
in particular are as follows:

              Before          After
              Mean   StdDev   Mean   StdDev  Confidence  Change
6:2 total     370.8  17.0     348.8  20.1    99.9%       +6.3%
6:2 function  46.4   8.4      45.8   6.6     18.0%       +1.2%  (insignificant)
8:2 total     343.2  19.0     339.1  15.4    54.7%       +1.2%  (insignificant)
8:2 function  38.9   3.9      40.2   6.9     52.4%       -3.2%  (insignificant)
6:6 total     658.4  15.7     604.6  20.8    100.0%      +8.9%
6:6 function  109.0  8.7      59.5   5.4     100.0%      +83.3%
8:8 total     896.2  24.5     766.4  17.6    100.0%      +16.9%
8:8 function  223.4  12.8     93.8   5.0     100.0%      +138.3%

The assembly version has also been tested with a fuzz tester to ensure that
any combinations of inputs not exercised by my available test streams still
generate mathematically identical results to the C version.
truehd: tune VLC decoding for ARM.

Profiling on a Raspberry Pi revealed the best performance to correspond
with VLC_BITS = 5. Results for overall audio decode and the get_vlc2 function
in particular are as follows:

              Before          After
              Mean   StdDev   Mean   StdDev  Confidence  Change
6:2 total     348.8  20.1     339.6  15.1    88.8%       +2.7%  (insignificant)
6:2 function  38.1   8.1      26.4   4.1     100.0%      +44.5%
8:2 total     339.1  15.4     324.5  15.5    99.4%       +4.5%
8:2 function  33.8   7.0      27.3   5.6     99.7%       +23.6%
6:6 total     604.6  20.8     572.8  20.6    100.0%      +5.6%
6:6 function  95.8   8.4      68.9   8.2     100.0%      +39.1%
8:8 total     766.4  17.6     741.5  21.2    100.0%      +3.4%
8:8 function  106.0  11.4     86.1   9.9     100.0%      +23.1%
truehd: break out part of output_data into platform-specific callback.

Verified with profiling that this doesn't have a measurable effect upon
overall performance.
truehd: add hand-scheduled ARM asm version of ff_mlp_pack_output.

Profiling results for overall decode and the output_data function in
particular are as follows:

              Before          After
              Mean   StdDev   Mean   StdDev  Confidence  Change
6:2 total     339.6  15.1     329.3  16.0    95.8%       +3.1%  (insignificant)
6:2 function  24.6   6.0      9.9    3.1     100.0%      +148.5%
8:2 total     324.5  15.5     323.6  14.3    15.2%       +0.3%  (insignificant)
8:2 function  20.4   3.9      9.9    3.4     100.0%      +104.7%
6:6 total     572.8  20.6     539.9  24.2    100.0%      +6.1%
6:6 function  54.5   5.6      16.0   3.8     100.0%      +240.9%
8:8 total     741.5  21.2     702.5  18.5    100.0%      +5.6%
8:8 function  63.9   7.6      18.4   4.8     100.0%      +247.3%

The assembly version has also been tested with a fuzz tester to ensure that
any combinations of inputs not exercised by my available test streams still
generate mathematically identical results to the C version.
Enable PYTHONOPTIMIZE for Pi
[PiSink] Ensure audio buffers use reasonable sized chunks

Previously the sink tried to consume exactly the number of samples required to maintain the desired audio latency.
That has a problem that we reapeatedly get called, and just consume a few samples each call.
As the cost of sending the data to the GPU is quite high, this results in a lot of CPU being used.
This changes the buffering to sleep for a quarter of buffer size, which ensures the samples submitted are always at lease a quarter of the total

Also, now the latency is never more than AUDIO_PLAYBUFFER, so report that directly in GetCacheTotal.
[PiSink] Add support for float and 32-bit formats

Significant CPU is consumed in converting audio to the sink's format, so add support for common formats to the sink.

Requires update firmware to handle this
[PiSink] Fix multichannel and passthough

The current Pi sink has random speaker allocation and plays noise when passthrough is enabled.
This adds messages to gpu to describe speaker layout for multichannel, and signal when passthrough is used
fixing both these issues
[PiSink] Increase Pi Sink's buffering

We do get underruns and breakups at 50ms latency. Increase to 100ms.
[rbp] Hardware accelerated resampling

This replaces the format conversion, up/down mixing and resampling code from ActiveAE with a GPU accelerated version.
Should significantly reduce CPU when using paplayer or dvdplayer.

Requires updated firmware
[ffmpeg] Speed up wtv index creation

The index creation is O(N^2) with number of entries (typically thousands).
On a Pi this can take more than 60 seconds to execute for a recording of a few hours.

By replacing with an O(N) loop, this takes virtually zero time