search

igorski / MWEngine

Audio engine and DSP library for Android, written in C++ providing low latency performance within a musical context, while providing a Java/Kotlin API. Supports both OpenSL and AAudio.
MIT License
259 stars 45 forks source link

sizeof(long) equal 8 #97

Closed stylixpro closed 4 years ago

stylixpro commented 5 years ago

fileSize in wav_header is long type. In my phone(Xiaomi Mi A2 Lite), sizeof(long) returns 8. So, it cannot read wav file properly. There are a lot of long type variables in source code. How can I fix it?

igorski commented 5 years ago

Hi there.

It is correct that the long data type corresponds to being 8 bytes (64 bits) in size. As such, the Xiaomi's architecture should present no problem. The fileSize portion of a WAV header describes the content length in bytes, as such it can represent a value of up to 9,223,372,036,854,775,807 bytes which is a big WAV :)

What is the exact issue you are experiencing ? Is there a WAV file that fails to load correctly ? Could you give some steps to reproduce the issue and what your expectation of these steps is ?

stylixpro commented 5 years ago

Line 93 in wavereader.cpp, header.fileType is RIFF but header.format, header.formatName are garbage values.

filzeSize of wav_header is 8 bytes. so fread( &header, sizeof( header ), 1, fp ); cannot read header properly.

In my other phone (Galaxy S4) it works good.

igorski commented 5 years ago

I realise now that I was confused about the issue. The long data type should indeed be 8 bytes, but the largest data type in a WAV header is only 4 bytes! As such I had been using the wrong data type. So how come this wasn't an issue during tests?

The mention of the Galaxy S4 and it working there helps. The S4 uses ARMv7 as the architecture and the Xiaomi on the other hand ARMv8-A. If in Application.mk the APP_ABI target "arm64-v8a" is enabled (it is by default) and the build instructions are used as described in the README file, the engine should build for that ARMv8-A processor, meaning that it will run an actual 64-bit version of the library instead of running in compatibility mode (where a long for 32-bit architecture is actually 4 bytes, making my initial error work under this mode).

I have to think about creating a compiler preprocessor for this use case (the use of long elsewhere in the library should lead to no errors as it will just provide a larger range for values, for file reading/writing it is obviously an issue as the data format should adhere to a standard).

In the meantime: can you verify whether loading the WAV works on both devices if you replace all declarations of unsigned long (in _struct wavheader in wavereader.cpp) with unsigned int ?

igorski commented 5 years ago

Ingore my last message. Can you pull the latest master branch ? In the latest commit I have added a fix where integer data types are used explicitly with their expected data size where applicable (e.g. wave reading).

igorski commented 4 years ago

Closing as this has been verified by others to address the issue described here.