True, latency is my current main concern.
I am able to make the stereo playback working, but unfortunately have
an issue with the stereo recording. The audio from the stereo
recording doesnt sounds right, it sounds like the audio is played in a
wrong frequency, and there is lots of electronic noise.
So I printed out the first 10 data I got from the callback, it looks
quite strange to me:
01-27 16:24:09.710: in recording 406 406 532 532 133 133 -102 -102
01-27 16:24:09.710: in recording -193 145 335 63 -402 -131 -45 -284
01-27 16:24:09.710: in recording 822 822 441 441 70 70 54 54
01-27 16:24:09.710: in recording -80 -80 -176 -176 137 137 200 200
01-27 16:24:09.710: in recording -560 -560 -141 -141 265 265 281 281
01-27 16:24:09.710: in recording -227 -227 -284 -284 12 12 245 245
You can see that there are always more than 1 stack of data is not
duplicating each sample, and this happens every 5 callbacks. And all
the data doesnt look right, they are too big and varying too much.
Has any one ever tried stereo recording in Nexus S? I dont really want
to spend much time on investigating it here if the problem is in the
01-27 16:24:09.066: DEBUG/---GIPS AD---(4982): in recording -567 -567
-328 -328 -178 -178 46 46
On Jan 27, 1:34 pm, mic _ <***@gmail.com> wrote:
> >> I found it interesting that on my galaxy s, it used the same buffer size
> for mono and stereo
> That's likely to be true for all Android phones using Qualcomm platforms.
> Regarding stereo recording: some (maybe most?) current devices will just
> record from a single mic and duplicate each sample to get a stereo signal.
> Some might actually do stereo recording with two mics. But I guess it's
> mainly the latency you're after here - not how the recording sounds.
> On Thu, Jan 27, 2011 at 12:54 PM, Shijing Xian <***@gmail.com>wrote:
> > Thanks Robert, it is definitely interesting to know how much it
> > improves the latency by using the stereo audio. It may likely match
> > what Robert said, half of the latency of mono. But I am not sure if
> > 44.1khz makes any difference, I tried the 44.1khz, 16khz, 8khz mono
> > recording/playback before, all the tests showed a similar latency,
> > unfortunately.
> > There are also some other reasons why I prefer 16khz to others, the
> > most important one is 16khz is usually supported by almost all Android
> > devices.
> > I will try the stereo recording and playback, and paste what I find
> > here later. In order to identify the problem, I will try stereo
> > recording and playback separately. So the combination will be:
> > stereo recording + mono playback
> > mono recording + stereo playback
> > stereo recording + stereo playback
> > And it will take a while.
> > On Jan 25, 8:31 pm, Robert Green <***@gmail.com> wrote:
> > > Would you be willing to rerun your tests at 44.1khz stereo? I found
> > > it interesting that on my galaxy s, it used the same buffer size for
> > > mono and stereo which made it so that stereo would have half thelatencyof
> > mono. I'm wondering if that's also the case on the nexus
> > > s. It's still horriblelatency, but half as horrible. :)
> > > On Jan 24, 7:42 am, Shijing Xian <***@gmail.com> wrote:
> > > > Hello Guys,
> > > > I think we had pretty much discussion or complain on this 45ms "low-
> > > >latency", but still we may be lack of a good overview on the android
> > > > audio system and may forget or miss some piece of important
> > > > information.
> > > > I am recently doing a experiment in Nexus S using this native audio
> > > > implementation for steaming, and get some interesting numbers, I hope
> > > > they can be usefully and spur more discussions.
> > > > I made a loopback application, which gets data from the recording
> > > > device, puts the data to a ring buffer, and playout. All the data
> > > > processing(if any) is using a framesize of 10ms audio.
> > > > Setups for the native audio implementation:
> > > > Recording: simple buffer queue, two buffers with size of 10ms audio
> > > > for each.
> > > > Playback: buffer queue, two buffers with size of 10ms audio for each.
> > > > When the app is started, it will enqueue an empty 10ms buffer to the
> > > > recording queue, and 10ms data buffer to playout queue, to keep the
> > > > queues rolling. In the recording callback function, I copy the data to
> > > > the ring buffer and enqueue 10ms empty buffer; In the playout
> > > > callback, I pull 10ms data from ring buffer and enqueue it to the
> > > > playback (if no data, it will gets zero buffer, no waiting here).
> > > > It is pretty simple, isn't it? And my calculation for the delay is
> > > > something like this: recording delay + playout delay + ring buffer
> > > > delay
> > > > recording delay should be less than '10ms(buffering) + continuous
> > > > inputlatency(50ms)'
> > > > playback delay should be less than '10ms(buffering) + continuous
> > > > outputlatency(45ms)'
> > > > ring buffer delay is depending on the amount of recording data has
> > > > been put into the ring buffer, and the amount of data has been played.
> > > > It is scaling to the size of buffer in the ring, and the ideal case is
> > > > that we playback the data soon after it is recorded. This ring buffer
> > > > delay is quite depending on how the callbacks come.
> > > > So my expectation for the maximum delay is : 115 + ring buffer delay.
> > > > (Please correct me if I miss something in my model)
> > > > Surprisingly, I got a delay of 360ms for this loopback test, where the
> > > > ring buffer delay is about 100ms on average.
> > > > To clarify how I do the measurement, I use alatencyinstrument which
> > > > inputs a beep to the microphone while listening to the speaker, and it
> > > > reports the interval.
> > > > I understand the Nexus S device is not a lowlatencydevice, and it
> > > > may have a bigger continuous input/outputlatency, but 250ms in 10ms
> > > > buffering is definitely not acceptable to me. And the worst thing is
> > > > that I have no clue where is consuming the time.
> > > > Note, I can't tell how much the playback and recording is taking part
> > > > in this 250ms delay separately now, and I will investigate on this
> > > > later.
> > > > And another issue I want to address here is about the way how the
> > > > callbacks come. In my setup, I have two 10ms buffers for each
> > > > recording/playback queue, so I am expecting the callbacks to occur
> > > > every 10ms. But it is not true in my test, instead I usually get two
> > > > or three callbacks with the same timestamp every 20-30ms. The worst is
> > > > that at the beginning of the call I often get a stack of callbacks at
> > > > the same time, for example, 7 recording callbacks with the same
> > > > timestamp, then the next recording callback comes after 70ms. That may
> > > > be the reason why I have a 100ms ring buffer delay in my test, but I
> > > > have no idea what is causing it. Guys, any idea here?
> > > > To compare the performance, I run the same test but using AudioTrack
> > > > in Java. most of the setup is similar to the native audio
> > > > implementation, except that I use polling instead of callback.
> > > > Basically I run two aggressive threads to pull data from the recording
> > > > and put data for playback.
> > > > And the overall delay is 280ms.
> > > > Any comment here to explain why the Java implementation has less
> > > >latency?
> > > > While the similar application for iPhone is reporting a 60-70ms
> > > > overall delay.
> > > > Note, in the above test I am using 16000 as sampling rate for both
> > > > recording and playback.
> > > > I am not sure if any of you have already done a similar experiment
> > > > like what I did, any comments or suggestion will be appreciated. And I
> > > > do wonder if there any API for me to tweak the performance? Or any API
> > > > to get the hardware or os delay to get the accuratelatency? (Though I
> > > > have already looked at the openSLES 1.0.1, but can't find any).
> > > > The only thing makes me happen is that the native audio implementation
> > > > does take less CPU usage, and the audio is more reliable than using
> > > > AudioTrack.
> > > > Best Regards,
> > > > /Shijing
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to email@example.com.
> > To unsubscribe from this group, send email to
> > firstname.lastname@example.org<android-ndk%***@googlegr oups.com>
> > .
> > For more options, visit this group at
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to firstname.lastname@example.org.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.