Maybe to describe the issue that is happening:
On stream start AE kindly asks Android to fill up the Sink with "Pause Data". As we are doing RAW Passthrough - AE is not generating Pause Bursts for this (it's an IEC container attribute) but kindly Calls Audiotrack with AddPause(20 millis). This Pause I receive and do like I would do something with it - but as I cannot generate PauseBurst for a RAW sink it is "assumed" that Android does that by itself under the hood. I therefore remember the 20 ms I got. Then I get 20 ms again, I remember them on top, etc. At a point I have 232 ms of Data remembered and tell to AE 232 ms as a Delay. Now the next AddPause call comes and I see that I already have 232 ms and don't add the new ones up, but rather "sleep for 20 mills" and report back to AE 232 ms. AE now knows: perfect the Sink is full and already in blocking mode - We can start.
AE now starts to deliver real audio packages. I put those onto the real sink. But - Android does not move right away, it might move after yet another 300 ms of real audio packages were added to the sink. After having real 232 ms audio packages - the "real sink" is full and might start moving. Therefore I have to return the new delay, which should at this point in time not be 232 ms but 232 ms (real payload) + the time I have rememberd as Pause bursts internally MINUS the time that has passed since then. So in short - I smooth that out in away that when I get 20 ms real payload but only need 2 ms to add them I sleep out another 8 ms to reduce my internal pause stuff .... at the end AE is still happy enough and we run with just the payload ... all good.
For Seek:
AE seeks in the video. But now needs to "feed out" the audio data on the sink. It's clear why: 200 ms in the sink, means 200 ms of "old audio" that does not fit to the new picture on screen. So AddPause starts again, but this time it's meant to "block out" the payload on the sink, meaning: every Pause I sleep away I also need to remember additionally as without the "faked payload" might go down and AE thinks: they have an issue moving the old stuff out.
So why is seek so hard. One needs to "transparently" distinguish both use-cases ... without knowing if seek has happened or warmup or something in the middle. And now combine this with "bad firmwares" and you have the mess
and know why it works for me and not for you or the other way round. This RAW API was a real bad idea. I think it's much better if AE would just seek and reopen the sink entirely ... though ... that will break those firmwares which have an issue syncing in general.
