Please help test some new android audio code!

[jules]

I've just added an OpenSLES audio device for android, in the hope of getting better latency than the java classes can manage.. But neither of my two devices or the emulator seems to be capable of supplying any kind of audio input to test!

If anyone's got a device that does handle audio (its OS needs to support API level 10 or greater), I'd really appreciate hearing if it works for you! I've tested playback, and that seems to perform better than the java audio, but I'd be really keen to find out:

a) if audio input works at all!
b) if it does, and you run the juce demo latency test, what kind of numbers are you getting for a given buffer size..?

Thanks!

[jfitzpat]

Well, I have an Asus Eeee Transformer TF101 here running 3.2.1 (api 13). Audio appears to work. Building today's tip without re-running introjucer on the JuceDemo project I get Latency results of:

19699 Samples (446.7 mS)
Reports Input 8192, output 16384
So correct is -4877 (-110.59 mS)

I then rebuilt the Introjucer the required -LD libs looks like it has changed to me (__android_log... perhaps?). Set the min SDK to 10, and saved. This did pass the JUCE_ANDROID_API define on the command line (10).

That did cause an "Android OpenSL" device to appear. It appears to record and play, but Latency Test always reports "Couldn't detect the test signal". The sound 'sounds' the same. Interestingly, switching to Android Audio doesn't make a difference. Still no latency test results, though record and playback work.

I don't have time to dig any deeper today, but let me know if there is something else you would like me to test.

[jfitzpat]

I just futzed with volume up and down and did get to two readings with the new device:

21746 Samples (493.1 mS)

And

20756 Samples (470.7 mS)

It reports that the input and output latency are 0, so the corrected remains unchanged.

NOTE, I'm only sporadically getting readings, so I may well be measuring an echo or something.

[jfitzpat]

OK, using a high tech plastic cup next to the built in speaker, cranked full, I can consistently get readings.

Android Audio comes in consistently at about 420-440 mS, OpenSL is consistently about 50-60 mS faster (358 mS was the best measured time).

Hope that helps.

[jules]

Thanks! Very interesting.

Very frustrating too, as looking at the OpenSL API, there seems to be no way at all to actually determine what these latency figures are going to be. Unbelievable that whoever designed the API would just completely fail to add such a basic and essential piece of information..

[peteatjuce]

HI Jules,

FWIW, I did mail the man in charge to suggest some changes in this area ... but never heard back.

Best wishes,

Pete

[peteatjuce]

I must say - that is pretty terrible latency.

[jules]

FYI: I've updated the class now, am attempting to use the AudioTrack classes to guess a vaguely realistic latency..

[peteatjuce]

Hi Jules,

FWIW, if you look at the libvlc project code (open-source video playback), you'll see that they try to use OpenES, but fall-back to pushing data to AudioTrack on earlier platforms... which might be a sensible approach?
In Mixtikl, we're not bothering with pre-Android 2.3, so that isn't a specific issue for me.

http://www.videolan.org/vlc/download-sources.html

HTH!

Pete

[jules]

FWIW, if you look at the libvlc project code (open-source video playback), you'll see that they try to use OpenES, but fall-back to pushing data to AudioTrack on earlier platforms... which might be a sensible approach?

Yeah, that's what my stuff does too.

[peteatjuce]

Cool

[X-Ryl669]

Jules, do you actually have an Android device ?

[jules]

Jules, do you actually have an Android device ?

Yes, a kindle fire (and my girlfriend has an old android phone too). The kindle's ok, but has no audio input.