Apple iOS development - audio sounds fast forwarded

[djliquidice]

Does anyone here have experience with iOS audio development that could lend a quick hand?

Code: [Select]

   
    int16_t *tempBuffer[bufferSize];

    for (int i = 0; i < NUM_BUFFERS; i++) {
       
        AudioQueueBufferRef mBuffer;

        AudioQueueAllocateBuffer(mAudioQueue, bufferSize, &mBuffer);

        mBuffers[i] = mBuffer;
       
        openmpt_module_read_interleaved_stereo(mod, PLAYBACK_FREQ, bufferSize, mBuffer->mAudioData);

        AudioQueueEnqueueBuffer(mAudioQueue, mBuffer, 0, NULL);
    }

The following implementation of ModPlug works fine:

Code: [Select]

    int bufferSize = 1024;

    for (int i = 0; i < NUM_BUFFERS; i++) {
       
        AudioQueueBufferRef mBuffer;

        AudioQueueAllocateBuffer(mAudioQueue, bufferSize, &mBuffer);

mBuffers[i] = mBuffer;
        mBuffer->mAudioDataByteSize = bufferSize;
        ModPlug_Read(mpFile, (char*)mBuffer->mAudioData, bufferSize);

        AudioQueueEnqueueBuffer(mAudioQueue, mBuffer, 0, NULL);
    }
   
Demo of the problem: https://www.youtube.com/watch?v=naSXx_xh0AY

Any suggestions would greatly be appreciated.

[manx]

Code: [Select]

   
                openmpt_module_read_interleaved_stereo(mod, PLAYBACK_FREQ, bufferSize, mBuffer->mAudioData);


In contrast to libmodplug, which takes the buffer size in bytes, libopenmpt takes the buffer size in number of sample frames.
This means, you have to devide the bufferSize by the number of channels (2 in the case of stereo in this case) multiplied by the size of an individual sample (sizeof(int16_t), or just 2 in this case).

i.e. replace the line quoted above with

Code: [Select]

   
                openmpt_module_read_interleaved_stereo(mod, PLAYBACK_FREQ, bufferSize / (2*sizeof(int16_t)), mBuffer->mAudioData);


[djliquidice]

OMG. 

I completely missed that

Your suggestion worked like a champ!!!

[manx]

On a related note, as we do not regularly test on Apple platforms and have never been testing on iOS at all:
Did you have to make any modifications to libopenmpt itself in order to make it work on iOS? If yes, we would like to make the necessary modifications to the upstream source in order to aid other iOS developers.

[djliquidice]

Hi Manx,

There were some structural changes that had to be made.  This is Such a huge codebase. to get things working, I had to remove quite a bit.

Is it possible to make changes that leverage header search paths over relative paths?

I can tell you that by adding the raw source files to an xcode project causes major pain .

I'd *love* to see what I can do to assist with helping migrate libopempt to being iOS friendly.  Should I just ask questions here? I'm not very familiar w/ the internals, but I believe w/ enough help from you & other contribs, we can make this happen =).

[manx]

I'm not sure what your talking about when saying "structural changes" and "removing quite a bit". Both really should not be required and will possibly make keeping your version up-to-date way harder than it needs to be.
The search path required by libopenmpt code is in particular the root directory of the source tree (i.e. adding "-I." if building relative to the source tree root) and to common directory (i.e. "-Icommon")
Could you provide a copy of the libopenmpt source tree you ended up using after your modifications, so we can take a look at it?
Also, feel free to ask further more specific/detailed questions here.

[djliquidice]

Hi @Manx,

Thank you for responding. I apologize for not getting back to you.   I had to shift my focus elsewhere.

I was reminded by the latest release of openmpt (congrats to you guys & the community) that my work here wasn't done.

I tried to create an iOS library again and here's the steps I had to take:

(Add files means add files to xcode project)

- Create common/ group
    - Add files
- Create include/modplug, include/stb_vorbis group
    - Add files

- Create libopenmpt/ group
    - Add files

- Create soundlib/ soundlib/plugins, soundlib/plugins/dmo groups
    - Add files

- Remove libopenmpt/
    - xmp-openmpt.cpp
    - in_openmpt.cpp
    - libopenmpt_plugin_gui.*
    - foo_openmpt.*

- Configure header search paths as $(SRCROOT)/  -- recursive

- Add "Other C flags":
-DMPT_WITH_ZLIB
-DMPT_CHARSET_CUSTOMUTF8
-DLIBOPENMPT_BUILD

Github repo is here: https://github.com/ModusCreateOrg/libOpenMPT-ios

[Saga Musix]

So it's just a matter of setting up a proper Xcode project. We already use Premake to generate Visual Studio solutions, so it could generate Xcode project files automatically as well, I guess.

[djliquidice]

@Saga Musix,

Yes. I believe it's entirely possible to automate that.

I'm no expert, but I've been a customer of such an automated process.

There is a tool here that may be of help: http://www.rubydoc.info/gems/xcodeproj/frames

I can start testing this process out and work on an example project. Integrating it with the greater libOpenMPT source & automation process is something i have zero experience in.

[Saga Musix]

Well, there's no need to drag in yet another scripting language and meta build tool if ours can already do it. I think we could look into adding an Xcode project to the output of our Premake config. If you want to try it yourself, get Premake 5.0, and call it with the parameters "build/premake/mpt-libopenmpt.lua xcode" (you will of course have to take care of of specifying that relative path correctly). Similarly, you can create a project for ext-stb_vorbis.lua, but I wonder if libvorbis could be used on OSX/iOS instead? If it's available, it's a better choice than stb_vorbis.

[manx]

It is probably better to support system installed libraries instead of bundled libraries for OSX. However, I have no idea how to properly integrate XCode with libraries installed via e.g. homebrew. Depending on system-installed libraries might also be better covered by the autotools build system anyway, so it may actually kind of make sense to build all external libraries with XCode like we are doing with MSVC. I have no opinion here as I am not a Mac developer.

Long story short: I (or better we) have absolutely no idea what would bee workable or common workflows and system setups for developers on OSX/iOS.