I’ve noticed that ByteArray is big endian by default by virtue of:
private var littleEndian:Bool = false;
in ByteArray.hx. Was this a conscious design decision? This means that anything that passes a ByteArray to lower level drivers, such as dynamic audio, must set the endianness of the native endianness of the target or the driver will read incorrect data.
Can I change this to default to the native endianness of the target?
Do we have a way to get the native endianness of the current target or must it be done wuth #if’s?
I think that endianness is something that would have to be investigated more. I have a feeling that most code is probably being treated as little endian, since ARM and x86/x86_64 can use little endian. We have not had notable issues in using the current ByteArray implementation across all the targets we support, but especially with communicating with servers, I understand how having this handled properly could be important, or in dealing with big endian systems, such as PowerPC (used by the Wii U) or in some embedded systems (like TiVo uses)
Yeah, don’t want to rush into this one without thinking it through.
Well what I’d like to do is this:
In the constructor for openfl/event/SampleDataEvent.hx, I’d like to uncomment the code that creates a ByteArray so that it more closely matches what flash does. (At the moment, you have to manually create this array if your target is not flash. Flash automatically creates it, so on that target, you don’t have to create it yourself.) I am assuming a goal of openfl is to match flash/AS3 as closely as possible.
But, wherever this ByteArray is created, the endianness must match the target platform. If it doesn’t, then when these bytes are read out in OpenALChannel::QueueBuffer(), they’re read incorrectly. I can set the littleEndian flag correctly right in SampleDataEvent and that won’t have unintended consequences outside of dynamic audio.
Yeah, I think that sounds reasonable, we can control the behavior of the SampleDataEvent to make it behave like we want consistent to Flash, then long-term, we can unpack some larger considerations of endianness, but for the moment, not have to worry too deeply
