E61 & E71 - differences in CMdaAudioInputStream?

[arijr]

I have developed an audio app using Nokia E61 & S60 3rd. For continuous audio sampling it uses extensively the CMdaAudioInputStream framework. I pass a 4k buffer to MMF and when the MaiscBufferCopied gets hit I get 4k worth of data each time. All fine and written assuming things stay pretty much this way (bad me...).

Now I've been trying out the same with 3rd FP1 SDK for E71. No code changes, same sampling rate. Surprisingly the callback gets hit roughly 3-4 times more often thus suggesting the copied audio bytes is far less than 4096 - my debug output files indeed reveal that most of the written frame (4096 bytes) is silence.

Hmmm, in MaiscBufferCopied desc's Length() return 4096 bytes which is correct in a way but all of it is not proper data. Any utility function/trick to verify the exact audio buffer size from MMF?

Big thanks!

-Ari

[Sorcery-ltd]

Hi,

Sounds like a bug to me. If the buffer isn't filled with real data when it's returned it should have the length set appropriately.

I'm not sure what hardware the E71 uses but there's a knowledge base entry in the wiki with a known issue about this for some earlier phones (5500 sport was one I think). The buffer size used is 1540(ish) - the exact figure's in the wiki.

Sorcery

EDIT: Buffer size for CMdaAudioInputStream on 5500 sport is 1600 for those that can't be bothered to follow the link.

[arijr]

Thanks Sorcery.

I presume you were refering this article:

KIS000456 - Differences in audio streaming configuration on the S60 3rd Edition devices
http://wiki.forum.nokia.com/index.ph...dition_devices

Power of 2 values would have been nice. I guess I will have to trick around to determine the effective buffer size in this specific case e.g. by prefilling the buffer with some known "not-likely-to-occur" values. I'll post my findings to this thread then.

-Ari

[Sorcery-ltd]

Before experimenting you could see if you can get useful values out of the iBufferSize member returned from the Config() function in CMMFDevSound? (need API from the plug-in pack for this). I've been meaning to check it for ages but haven't had the time. You might need to initialize DevSound in the appropriate mode before it gives the answer you're looking for, or it might not work at all.

Sorcery

[arijr]

I coded some lines to reveal the 1600 byte magic number. Like suspected MaiscBufferCopied gets called when 1600 bytes (800 16-bit PCM) samples have been captured. This is actually better - reducing the latency nicely and appx. 100+ ms gap still leaves good room for DSP in same thread. That Length() method does not seem to return a correct value at any time...

Sample rate was 8000Hz, PCM-mode, not tested with other rates/modes as this is the domain of interest.

DUT
Nokia E71
110.07.127
09-10-2008
RM-346

MaiscBufferCopied entry clocking and sample counting

Since Last  16-bit PCM     TDesC Length()
Entry ms
-		0		4096
251		0		4096
132		800		4096
143		800		4096
170		800		4096
125		800		4096
186		800		4096
201		800		4096
233		800		4096
216		800		4096
115		800		4096
172		800		4096
93		800		4096
124		800		4096
176		800		4096
94		800		4096
195		800		4096
93		800		4096
157		800		4096
179		800		4096
94		800		4096
122		800		4096
...