Namespaces

Variants
Actions

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

Customizing the buffer size of CMdaAudioInputStream

From Wiki
Jump to: navigation, search

Archived.pngArchived: This article is archived because it is not considered relevant for third-party developers creating commercial solutions today. If you think this article is still relevant, let us know by adding the template {{ReviewForRemovalFromArchive|user=~~~~|write your reason here}}.

The article is believed to be still valid for the original topic scope.

Article Metadata
Compatibility
Platform(s): S60 2nd Ed, Feature Pack 2
S60 2nd Ed, Feature Pack 3
S60 3rd Edition
S60 3rd Edition (initial release)
S60 2nd Edition (initial release)
Article
Created: User:Technical writer 2 (09 Mar 2006)
Last edited: lpvalente (11 Aug 2014)

Overview

Customizing the buffer size of CMdaAudioInputStream

Description

Is it possible for S60 MMF audio client applications to customize the buffer size used for input streaming in S60 devices?

Solution

The default audio I/O data buffer size under S60 MMF is optimized according to the sound hardware and audio codec characteristics. Client applications using CMdaAudioInputStream should take these limitations into consideration:
When using the PCM16 (default) format:
Input buffers returned by the sound device are always either 320 bytes (S60 2nd Edition, FP2 and FP3) or 4096 bytes (S60 3rd Edition). These are also the maximum data lengths that can be returned per CMdaAudioInputStream::ReadL() call, so there is no point in using buffers larger than these values.
If a client-side buffer passed to ReadL() is smaller in size, the server-side buffer is divided into blocks that fit the client buffers. If this division is not exact but leaves a remainder, some buffers returned to the client are not filled to the maximum length. For example, when using a buffer size of 3840 bytes on S60 3rd Edition, the first returned buffer is 3840 bytes, and the next one is (4096-3840) 256 bytes, then 3840 bytes again, and so on.
When using non-PCM formats for streaming:
For a compressed audio format, each returned input buffer typically contains a single frame of audio data. For example, when configuring the stream to use AMR-NB format (in the MaiscOpenComplete() method):
   iInputStream->SetDataTypeL(KMMFFourCCCodeAMR);
After this, each returned buffer will contain 14 bytes (a single AMR-NB frame in mode 1, 5.15 kbit/s) representing 20 ms of audio data.

This page was last modified on 11 August 2014, at 19:03.
37 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×