...Unfortunately, after a little bit of testing and a lot more thought and consideration, I've realized there really isn't a way to do this without doubling the allocation. Ouch.
Followup to these two commits:
02617a854dad3a632927
In the second commit, the buildBuffer call in HTTPRequest was
found to conflict with the way local requests are made, with the
bytes being set directly. So buildBuffer was moved to NativeHTTPRequest
instead. Upon promise completion, now, the value of bytes should always
be correct, and buildBuffer need not be called.
But buildBuffer is called again in NativeHTTPRequest.loadText. For local
requests, this will lead to the same problem that the second commit
fixed (presumably), and for network requests, this leads to the nulled
out buffer being accessed a second time, resulting in a crash.
So since the received value of bytes is already correct and buildBuffer
is harmful, the buildBuffer call is removed from loadText.
Both local and network requests are happy now!
The sourcePlay call in NativeAudioSource.play is removed, since
setCurrentTime will always do that itself. Additionally, within
setCurrentTime, sourcePlay was happening before setting the byte
offset for non-streamed sounds.
This appears to fix the problem of sounds playing the first part
multiple times, described here:
https://community.openfl.org/t/sounds-play-twice-on-ios/12163
This change places the focus on the one known use case, while clearing
up potential confusion caused by similar-sounding classes that function
totally differently.
Previously, they could access `${app.file}` and `${config.android}`, but
not `${project.platformType}` or `${config.android.target-sdk-version}`.
Now they can!
I don't know if we want to phase out `${projectDirectory}`, but it's now
an option.
vorbisFile.timeTell() returns the current decoding offset in seconds,
and it's updated each time vorisFile.read() is called. Since data is
buffered by calling vorbisFile.read() multiple times, the associated
time values also need to be preserved in order to get the correct time
offset.
Without this change, getCurrentTime() will return some time in the
future relative to the amount of buffered data.
It isn't always safe to assume `./` is the app directory, and removing
that assumption opens up options.
Requires at least Haxe 3.4, but I don't think Lime supports 3.3 anyway.
Turns out, `HTTPRequest`'s call is only needed for internet requests.
Files on the local machine will be loaded directly into `bytes`, leaving
`buffer` empty. Calling `buildBuffer()` will then delete the data.
Pros: It's a standard Haxe feature that other Haxelibs may rely on. Plus
it offers built-in thread safety, unlike `onUpdate`.
Cons: It incurs two `mutex.acquire()` calls per frame.
