This change fixes playerImpl leak by removing dependency on
finalizer usages. Now readLoop can (or should) be called multiple
times even after closing. Only when (*Player).Close is called
explicitly, the read loop cannot be started again.
Fixes#852
This is basically reland of
2fee7a6fe5.
Before this change, if a player's buffer was not enough for
reading, 0 value were used and this caused noises. The reading
size should be aligned with all the players.
However, there are some cases that the player should be skippped.
For example, just after a player just starts playing or seeking,
the buffer is empty. In this case, other players should not wait
for the player since decoding might take some time. Another case
is that the player reached EOF.
This change aligns the read buffer sizes but use zero values only
when the player just starts or seeks, or reaches EOF.
Before this change, if a player's buffer was not enough for
reading, 0 value were used and this caused noises. The reading
size should be aligned with all the players.
Just after a player just starts playing or seeking, the buffer is
empty but other players should not wait for the player read since
decoding might take some time.
To summerize, this change aligns the read buffer sizes but use
zero values only when the player just starts or seeks.
Syncing was already incomplete (e.g. decoding takes more than one
frame and delays can happen in this case). Giving up syncing audio
timer and game timer should not affect the game experience so much.
Instead, clock implementation will be much simpler.
Before this change, the audio is suspended when the game stops for
1/12[s]. However, as game often stops for more than 1/12[s]
especially on mobiles, this implemntation caused some audio
glitches.
This change fixes this problem by re-implementing suspending/
resumeing audio by detecting the window is active/focused or not.
nosync package is good in terms of performance, but this assumes
that duplicated lock never happens. As audio package runs multiple
goroutines, theoretically duplicated lock can happen, and it looks
like this is an actual case (#603).
This change replaces nosync usages with regular sync usages.
Probably I'll deprecate nosync usages via internal/sync package
everywhere in Ebiten.
This might fix#603.
