iOS sound dev - is this audio data I'm getting?

[ngocdh]

So as mentioned in pull request #1450, I'm trying to deal with iOS audio. But I have no dev experience (really!), apart from some basic dev lessons I took a long time ago. So I need your help.

It seems I managed to obtain audio data from the mic when connecting to a room, but I'm having trouble passing this data to CSoundBase::ProcessCallBack. Everytime this function is called, I have this error message:

AURemoteIO::IOThread (24): EXC_BAD_ACCESS (code=1, address=0x21)

on this line bCallbackEntered = true

It's like the CSound object is not yet initialized, which is why I have an access error (not sure though).

So I put a printf in my CSound init function, and surprise: the printf is called a lot of times when the app loads, and once when I try to enter a room. And I thought this Sound object from Client.cpp is initialized only once? Have to check this again.

Anyway, this is how I got audio data from the mic:

AudioUnitRender(cd.rioUnit, ioActionFlags, inTimeStamp, 1, inNumberFrames, ioData);

I got 128 frames in ioData (4 bytes each), which I printed out like this

for(UInt32 j = 0; j < inNumberFrames; j++)

            printf("%02X", ((Float32*)ioData->mBuffers[0].mData)[j]);

And got:

00C00000004000000000C0000000800000008000000000C0000000A0000000600000000060000000800000008000000000600000006000000000A0000000A000000000A00000006000000000E000000080000000C00000004000000040000000400000004000000080000000800000004000000020000000400000004000000000A0000000004000000020000000800000000000E00000004000000040000000E0000000A000000020000000000000400000000040000000E0000000A00000008000000080000000C0000000800000004000000020000000600000000040000000200000006000000020000000C00000006000000040000000C0000000A0000000800000002000000080000000C00000008000000020000000C000000060000000E000000040000000C0000000C0000000C00000004000000020000000C00000002000000060000000C00000004000000020000000000000800000008000000040000000A0000000C000000080000000A0000000C000000000E000000080000000C0000000400000008000000000400000006000000000A0000000E0000000004000000040000000C0000000C000000060000000E0000000

Notice it's not the full 128 frames. Any idea why?

And MOST IMPORTANT QUESTION of this post: do you think this is even valid audio data?

[ngocdh]

And I thought this Sound object from Client.cpp is initialized only once? Have to check this again.

Ok actually CSound is init() 4 times in CClient::Init() to check the sound card capabilities. However from the logs, I get 36 inits when app loads, and 4 inits when connecting...

[ngocdh]

Ok I got passed the access error. Indeed there were issues when initialising objects. Now ProcessCallback seems to be called correctly, in the UI I got to the point where the input slider moves up, almost red though (I wasn't making any sound).
But then I got a Heap corruption (malloc: Heap corruption detected, free list is damaged at 0x...). Maybe because I didn't care much about buffer sizes. Or maybe I should use @j-santander's RingBuffer implementation (not sure it has anything to do with the Heap corruption).
P/S: sorry for the spams, I'll try to limit my progress updates.

[j-santander]

Thanks for bringing that back to my attention. I actually found there were some mistakes in my ring buffer that I should probably fix. I'll try to do it over the weekend.

However, looking through the code recently I believe there already some ring buffers available in the common code (?) Perhaps some of the main developers can confirm and we perhaps we should unify.

[ngocdh]

oh @j-santander just to be clear I'm not saying there's anything wrong with your code. I'm thinking about using your code to handle buffers, not sure though if it helps with my Heap corruption issues.
Glad that I could at least remind you of some mistakes to fix. But as a feedback, I haven't experienced any issue with android's sound.

[j-santander]

Sorry about the delay, just submitted the pull request #1528. I've replaced the use of my home-grown RingBuffer in android code with the CBuffer that was already available in the common code.

[pieterbos]

I wonder, since both iOS and Mac OS X use CoreAudio, with either the same or a very similar API, can't you just use most of the code of the current Mac OS X audio processing for iOS?

[ngocdh]

@pieterbos yes that's what I thought too. But the code for Mac is way more complicated, because it has to handle multiple devices. I chose to start simple, and follow Jamulus Android code and a sample code from Apple for iOS.
But now that I'm a bit more familial with Apple's code, maybe I can have a better look at the code for Mac and bring things together, thanks for the idea.

[ngocdh]

Also, there are a few CoreAudio libraries in Mac not available for iOS.