15

Does anybody know how to fix this warning message?

07-14 10:38:55.411 V/tracker-audiotest(22426): Recording Thread::run(): start audioRecord recording. 07-14 10:45:51.490 "W/AudioTrack( 607): AUDIO_OUTPUT_FLAG_FAST denied by client due to mismatching sample rate (44100 vs 48000)"

When I test the audio latency on Android 4.4, I face a suddenly delay increasing after I saw this warning message. But I don't change the sample rate during the test and the initial setting is in 48kHz. This warning message happen after 7 minutes recording started.

You can test this project on your device if needed. The project is in GitHub:

https://github.com/garyyu/OpenSL-ES-Android-DelayTest

gary
  • 1,569
  • 3
  • 20
  • 30

3 Answers3

4

The AUDIO_OUTPUT_FLAG_FAST is denied because you are using a different rate than the one supported in hardware. You need to query the hardware supported sampling rate and record at that rate rather than hard code it to 48kHz.

ChocoBilly
  • 409
  • 3
  • 10
3

You may try to use Java function interface:

AudioManager myAudioMgr = (AudioManager) getSystemService(Context.AUDIO_SERVICE);  
nativeSampleRate = myAudioMgr.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE);

to retrieve the hardware default sample rate on your phone, use that to create the player.
Also try to use:

nativeSampleBufSize = myAudioMgr.getProperty(AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER);

to get default audio buffer size( it is in frames ) and use that for your playback.

You could look at the JNI sample code audio-echo if JNI is ok for you.

Rara
  • 639
  • 9
  • 22
Gerry
  • 1,223
  • 9
  • 17
  • I tried to run your program on my Android-M ( nexus 9 and nexus 5), the raw audio file plays back fine ( I used a music file, so any break would be obvious). your buffer is 480, on my devices, fast audio buffer sizes are: – Gerry Sep 22 '15 at 01:41
  • 240 frames/buffer, and frequency is 48Khz. I feel the playback is pretty smooth. Android-M has improvement for audio, you could check it out and see if it improves things in your end. – Gerry Sep 22 '15 at 01:49
  • Looking at the code, in the inner loop, it pulls in recorded audio first, write to the file[copied twice before bits got into the file]; then process the player by reading in one buffer of audio data, resample it, copy to play buffer [2 copies ]; then mix them and write out to file. Within one buffer play time, 5 copies, 3 file access, they must finish on time. If it is not finished, player or recorder is starving, will cause glitches. I think it might be better to let player and recorder have double buffer and enqueue a new buffer whenever callback happens. Read file in big chunks too. – Gerry Sep 22 '15 at 05:17
0

Try changing the sample rate at

frameworks/base/
frameworks/av/
hardware/libhardware

locations.

default sample rate is 44100 try setting the sample rate you want (your audio files have). it will work.

cheers.

Karan
  • 49
  • 2