CODEWITHSUNDEEP
androidaudioandroid-mediacodecaudiotrack
SarC
SarC

Reputation: 118

Android AudioTrack weird noise in Samsung Mobile

My Android application uses MediaCodec to decode audio stream and plays it using AudioTrack. When testing with Dell Venue 3830 (Intel processor,Kitkat OS) its playing fine, But when testing using Samsung GT-S7582 (Armv7 processor, JellyBean OS) its producing weird loud noise. Is there any way to overcome this noise?

Mediacodec decoder configuration

    String mimeType = "audio/3gpp";
    AudioDecoder = MediaCodec.createDecoderByType(mimeType);

    MediaFormat mMediaFormat = new MediaFormat();
    mMediaFormat = MediaFormat.createAudioFormat(mimeType,sampleRate,1);

    AudioDecoder.configure(mMediaFormat,null, null, 0);
    AudioDecoder.start();

AudioTrack Configuration

mAudioTrack = new AudioTrack(
                AudioManager.STREAM_VOICE_CALL, 
                sampleRate, 
                AudioFormat.CHANNEL_OUT_MONO ,
                AudioFormat.ENCODING_PCM_16BIT,
                AudioTrack.getMinBufferSize(8000,AudioFormat.CHANNEL_OUT_MONO,AudioFormat.ENCODING_PCM_16BIT)*8, 
                AudioTrack.MODE_STREAM);

Upvotes: 2

Views: 647

Answers (1)

mstorsjo
mstorsjo

Reputation: 13317

Generally, you may want to set up the AudioTrack only once you have got the INFO_OUTPUT_FORMAT_CHANGED from the decoder, and use info from the MediaFormat from MediaCodec.getOutputFormat setting parameters. E.g. for AAC, even if the file itself is mono, some decoders can decode it as stereo. (But that wouldn't produce loud noises, it would only make it sound twice as slow.)

Since you're decoding AMR-NB, not AAC, it's probably not returned at stereo, but you may still want to inspect the output MediaFormat to see if the decoder is returning data in some unexpected format.

You could also use MediaCodecList to look for another decoder, instead of relying on MediaCodec.createDecoderByType which just picks the first decoder. On most devices, there's the google SW decoder, but some devices can also have a HW decoder, which may behave differently. By manually iterating over the list and preferring the ones that start with OMX.google (like OMX.google.amrnb.decoder in your case), you may get more predictable behaviour. (For video, one generally don't want to use the SW codecs unless they're the only choice since there's a huge difference in performance between the two, but for audio the difference shouldn't matter too much in most cases.)

Upvotes: 2

Related Questions