1198184 - [FFOS_2.2][KeyPad] Key pad tone delays too much

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

[Lingling Zhao]

Attachment: keypadeTone.txt

Repreduction steps;
1.Open dialer.
2.Dial digit in the key pad.
3.The tone delays too much.

Please see the log in attachement, please check it by keyword 'KeyPadTone'.

Comment 1

[Gao Hongjie]

We also want to add log in gecko to track the tone start playing. Please help to check where we should put trace info to?

Comment 2

[Wesly Huang (EPM)]

Hi Guoqiang, Jasper:

I remember yesterday Jasper mentioned about some analysis you've already done, would you mind also put them here? Then we can know more context from you and avoid potential redundant work to increase the overall efficiency. Thanks!

Comment 3

[Guoqiang.CHEN]

Dear Wesly,

We add some log at app receive keydown event and audio_hw_primary start copy data.
it take about 60~80ms, In GC devices，it take about 100ms, have any way to decrease it?

Log like this.
01-01 10:14:51.679 I/GeckoDump( 9331): zll,key down to start tone---------app receive keydown event
01-01 10:14:51.719 I/GeckoDump( 9331): zll, envelopeNode to start-------- app start play.
01-01 10:14:51.719 I/GeckoDump( 9331): zll,oscNode to start
01-01 10:14:51.719 I/GeckoDump( 9331): zll,oscNode to start


01-01 10:14:51.739 D/audio_hw_primary( 8687): out_write bengin
01-01 10:14:51.739 V/audio_hw_primary( 8687): out_write: writing buffer (3840 bytes) to pcm device
01-01 10:14:51.759 D/audio_hw_primary( 8687): out_write bengin
01-01 10:14:51.759 V/audio_hw_primary( 8687): out_write: writing buffer (3840 bytes) to pcm device

Comment 4

[Guoqiang.CHEN]

We compare with other device, it is really slow
https://mega.nz/#!q5BSDAAB!yUxj5JeMSBR07NuwSYBqJEAipe4-cmND0gAATACwKIo

Comment 5

[Wesly Huang (EPM)]

Thanks Guoqiang, I'll talk this with Audio team people in Taipei first to see if they have some idea and can provide suggestion here.

Comment 6

[Alastor Wu [:alwu]]

Here are some related information.

According to [1], we can know that the FxOS use the libcubeb as the audio backend, and the libcubeb use the OpenSL_ES instead of directly using the Android::AudioTrack. In addition, the OpenSL_ES uses the "FastMixer" to playback audio. From the android document [2], the FastMixer should improve the audio latency, but from [3], someone improved the latency by disable the FastMixer. (I don’t know why...) Maybe you can also try it.

In addition, here is we send the specific latency to OpenSL_ES [4], it might be related with the hardware device.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1163820#c14
[2] https://source.android.com/devices/audio/latency_design.html#fastMixer
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1163820#c9
[4] https://dxr.mozilla.org/mozilla-central/source/dom/media/GraphDriver.cpp#557

Comment 7

[Simba Yao]

Hi Alastor,

How can I open the FastMixer?


(In reply to Alastor Wu [:alwu] from comment #6)
> Here are some related information.
> 
> According to [1], we can know that the FxOS use the libcubeb as the audio
> backend, and the libcubeb use the OpenSL_ES instead of directly using the
> Android::AudioTrack. In addition, the OpenSL_ES uses the "FastMixer" to
> playback audio. From the android document [2], the FastMixer should improve
> the audio latency, but from [3], someone improved the latency by disable the
> FastMixer. (I don’t know why...) Maybe you can also try it.
> 
> In addition, here is we send the specific latency to OpenSL_ES [4], it might
> be related with the hardware device.
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1163820#c14
> [2] https://source.android.com/devices/audio/latency_design.html#fastMixer
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1163820#c9
> [4]
> https://dxr.mozilla.org/mozilla-central/source/dom/media/GraphDriver.cpp#557

Comment 8

[Simba Yao]

Sorry,How can I disabled the FastMixer?

(In reply to Simba Yao from comment #7)
> Hi Alastor,
> 
> How can I open the FastMixer?
> 
> 
> (In reply to Alastor Wu [:alwu] from comment #6)
> > Here are some related information.
> > 
> > According to [1], we can know that the FxOS use the libcubeb as the audio
> > backend, and the libcubeb use the OpenSL_ES instead of directly using the
> > Android::AudioTrack. In addition, the OpenSL_ES uses the "FastMixer" to
> > playback audio. From the android document [2], the FastMixer should improve
> > the audio latency, but from [3], someone improved the latency by disable the
> > FastMixer. (I don’t know why...) Maybe you can also try it.
> > 
> > In addition, here is we send the specific latency to OpenSL_ES [4], it might
> > be related with the hardware device.
> > 
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1163820#c14
> > [2] https://source.android.com/devices/audio/latency_design.html#fastMixer
> > [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1163820#c9
> > [4]
> > https://dxr.mozilla.org/mozilla-central/source/dom/media/GraphDriver.cpp#557

Comment 9

[Alastor Wu [:alwu]]

In [1], change the flag to AUDIO_OUTPUT_FLAG_NONE.

[1] http://androidxref.com/4.4.2_r2/xref/frameworks/wilhelm/src/android/AudioPlayer_to_android.cpp#1442

Comment 10

[Gao Hongjie]

关于AUDIO_INPUT_FLAG_FAST问题，被拒绝的原因在AudioFlinger， frameworks/av/services/audioflinger/Threads.cpp
中间有个kUseFastMixer， 默认值是FastMixer_Static，会根据mFrameCount和mNormalFrameCount的值去决定是否使用FastMixer，
这里我没理解是怎么回事，只知道这个设定会使得FastMixer不被初始化
如果把kUseFastMixer设置成FastMixer_Always，则AUDIO_INPUT_FLAG_FAST会被传到底层
但是底层的log仍然是usecase(0: deep-buffer-playback)

Comment 11

[Gao Hongjie]

纠正#10中的笔误，应该是AUDIO_OUTPUT_FLAG_FAST

Comment 12

[Wesly Huang (EPM)]

Hi Jasper:

I've talked w/ Alaster and we'll need some time to check the file you mentioned. After that we'll see if directly update here, or may arrange a short call prior to it. 

(In reply to Gao Hongjie from comment #11)
> 纠正#10中的笔误，应该是AUDIO_OUTPUT_FLAG_FAST

Comment 13

[Alastor Wu [:alwu]]

Hi, HongJie,
Could you describe your question again? 
The FastMixer have enabled in FxOS [1]. If you want to disable it, from the comment in Threads.cpp, you should set |kUseFastMixer| to "FastMixer_Never".

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1163820#c14

Comment 14

[Gao Hongjie]

(In reply to Alastor Wu [:alwu] from comment #13)
> Hi, HongJie,
> Could you describe your question again? 
> The FastMixer have enabled in FxOS [1]. If you want to disable it, from the
> comment in Threads.cpp, you should set |kUseFastMixer| to "FastMixer_Never".
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1163820#c14

Hi Alastor,

We found keytone dalayed about 200ms after user pressed key in dialer screen. From BSP level, we found that for android project when playing DTMF tone, low_latency mode is used. This mode is used to reduce the delay time. But in firefox OS, this mode is always NOT available, it will always use deep_buffer mode which will cause much delay. The reason why we want to disable FastMixer is we want audioTrack be involved that will help us to set low_latency mode.

Comment 15

[Alastor Wu [:alwu]]

Hi, HongJie,
The FxOS doesn't control whether to use the low_latency or deep_buffer, because we use libcubeb instead of using the Android::AudioTrack directly. (except the AudioOffloadPlayer, but it's not related with this issue) 

Could you use "FastMixer_Never" to turn off the FastMixer? 
Because this kind of changing should be related with Android's AudioFlinger, not Gecko part.

Comment 16

[Gao Hongjie]

(In reply to Alastor Wu [:alwu] from comment #15)
> Hi, HongJie,
> The FxOS doesn't control whether to use the low_latency or deep_buffer,
> because we use libcubeb instead of using the Android::AudioTrack directly.
> (except the AudioOffloadPlayer, but it's not related with this issue) 
> 
> Could you use "FastMixer_Never" to turn off the FastMixer? 
> Because this kind of changing should be related with Android's AudioFlinger,
> not Gecko part.

Hi Alastor,

we have already tried to use "FastMixer_Never" but there is no improvement. we are checking with Qualcomm for it.

BTW, you mentioned that FxOS doesn't control the play mode, is that mean audio playing will always has a long delay?

Comment 17

[Alastor Wu [:alwu]]

Hi, HongJie,

In FxOS, we have two kinds of audio playback path, one is directly via AudioTrack, another one is via libcubeb / OpenSLES.

The first method is used by AudioOffloadPlayed, and it is for playing pure audio. Ex. Play music from the music app. We use this way to playback non-streaming audio element. The use case of Android audio playback is "compress-offload-playback".

The second one uses the libcubeb / OpenSLES, I don't sure about its Android's use case, because it depends on the implement of the OpenSLES and Vendor's AudioFlinger.

Back to your question, yes, if we use the "deep_buffer", then we would have a longer delay.

Comment 18

[Gao Hongjie]

(In reply to Alastor Wu [:alwu] from comment #17)
> Hi, HongJie,
> 
> In FxOS, we have two kinds of audio playback path, one is directly via
> AudioTrack, another one is via libcubeb / OpenSLES.
> 
> The first method is used by AudioOffloadPlayed, and it is for playing pure
> audio. Ex. Play music from the music app. We use this way to playback
> non-streaming audio element. The use case of Android audio playback is
> "compress-offload-playback".
> 
> The second one uses the libcubeb / OpenSLES, I don't sure about its
> Android's use case, because it depends on the implement of the OpenSLES and
> Vendor's AudioFlinger.
> 
> Back to your question, yes, if we use the "deep_buffer", then we would have
> a longer delay.

Hi Alastor，

Qualcomm sent us audio_policy.conf file which used in Android system. We are compraing it and have some test. If the modification works, we will continue to discuss how to set "low_latency" in Firefox OS level.

Comment 19

[Gao Hongjie]

(In reply to Alastor Wu [:alwu] from comment #17)
> Hi, HongJie,
> 
> In FxOS, we have two kinds of audio playback path, one is directly via
> AudioTrack, another one is via libcubeb / OpenSLES.
> 
> The first method is used by AudioOffloadPlayed, and it is for playing pure
> audio. Ex. Play music from the music app. We use this way to playback
> non-streaming audio element. The use case of Android audio playback is
> "compress-offload-playback".
> 
> The second one uses the libcubeb / OpenSLES, I don't sure about its
> Android's use case, because it depends on the implement of the OpenSLES and
> Vendor's AudioFlinger.
> 
> Back to your question, yes, if we use the "deep_buffer", then we would have
> a longer delay.

Hi Alastor,

After we made a change for audio_policy.conf, the low_latency mode works. Thank you for your support:)

Comment 20

[Alastor Wu [:alwu]]

No problem :)
According to the comment19, the issue is solved by modifying audio_policy.conf, close this bug.
If there are any questions, please reopen it, thanks.