AESinkAudioTrack: Try to aim 200 ms buffer and 50 ms periods

[fritsch]

Adjust Audio-Buffers to match other platforms.

A sink works as follows:
It has a buffer, which consists of certain amount of periods of audio.
If period size is too large, e.g. only 2 fit into a buffer, we might underrun if just 1 period comes too late.
If period size is far too small, you get a cpu problem, with e.g. 10 ms period you have to come back 100 times per second.

On pulse and on Alsa we aim at 200 to 400 ms buffer and have periods of around 50 ms. This has proven as a good ratio among cpu load, underruns, etc.

For Android, we used two times the minimum buffer allowed and half of it as period. The PR at hand increases the buffer size and tries to keep the period size as it was before to not create more load but to be more failsafe, when e.g. listening to high quality audio and switching towards the menu where a thread could get stuck for too long.

Old Audiotrack: 64 ms buffer and 32 ms period
New Audiotrack (on same hardware): 250 ms buffer and therefore 60 ms periods.

This solves issues for @HitcherUK when listening to music and going into the menus.

[fritsch]

In an ideal world, it would be good if the periods / buffers actually reflect the hw settings, but those are - in opposite to ALSA - not exposed for audio track.

[Hitcher]

Backport for 18.5 as this is a fix please.

[fritsch]

Needs a lot regression testing on several devices.

For example: AMLogic devices feedback (the old ones), FireTV 4K, etc.

Also: TrueHD, DTS-HD, etc. needs testing. Those are quite sensitiv when it comes to buffer / periods ratio.

[Hitcher]

@fritsch DTS-MA and Dolby-HD both working correctly.

[CiNcH83]

Might this also have an impact on the audio resample behavior for live sources? Frequency/rr fluctuations are still high on BRAVIA, causing audible distortion.

[fritsch]

@CiNcH83 Don't think so - rather sounds like a shitty mediacodec implementation which fluctuates all over the place.

[peak3d]

Tested on wetek HUB with no issues.