Customizing the buffer size of CMdaAudioInputStream
Article Metadata
Compatibility
S60 2nd Ed, Feature Pack 3
S60 3rd Edition
Article
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.
(no comments yet)