Peculiar issue calling lib from iPhone

We are using opus successfully from Windows and from Android (encode and decode - the Windows piece has been in use for over a year). However when called on iPhones we're getting strange results.

The calling code is C# and the code actually making the calls is shared by all platforms so we expected it to 'just work'. However what we're getting has us baffled.

• When presented with 320 int16s on both Windows and Android platforms opus_encode() writes 28 bytes to the output buffer and they look the same. We know that correct data is being generated.
• When called on the iPhone with the same input array opus_encode() writes 651 bytes to the output buffer. This consists of roughly 100 non-zero bytes, about 200 zero bytes then another 300 non-zero bytes. We have confirmed that by reducing the size of the target buffer and input buffer we can modify the behaviour (eg; if we say the output buffer is only 200 bytes then opus_encode() only writes 200 bytes). The bytes it writes are consistent each time. We've modified the opus_encode() source to display the input parameters and that shows that they are making the transition from C# to C correctly (we sprintf() to the output buffer and examine the output buffer back on the C# side).
• For what it's worth both Windows and iPhone are calling the 'non FIXED_POINT' version of the method.
• We have confirmed that other calls to the library (eg; getting the version) return valid results on iPhone.

Hence our bafflement. I've been programming for several decades and I have experience with calling external code. Usually if you get something wrong the code blows up. Or at least behaves very randomly. Yet our testing indicates that opus is being called correctly because it's stable. It's consistent. It's just the returned data is wrong. Very wrong.

Any thoughts?

Thank you.

Start by reproducing the iPhone call to opus_encode() with 320 int16s and compare its parameters and output with the Windows and Android results. Inspect the shared C# to C boundary, including the input and output buffer sizes, and compare the iPhone build's non-FIXED_POINT configuration. Done means identifying why the iPhone output differs and documenting or correcting the interop or build issue.