History log of /frameworks/base/media/libmedia/ToneGenerator.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
6c84d7313eb42d31449446cfb86ff71ee4a02bf5 14-Oct-2009 Naveen Kalla <nkalla@quicinc.com> Media/ToneGenerator: Change tone format for TONE_CDMA_ANSWER

Tone format for TONE_CDMA_ANSWER should be 660Hz + 1000Hz, with a 500ms ON
duration.
/frameworks/base/media/libmedia/ToneGenerator.cpp
bda7469d9b1ec6d9c9d6da40ddf64dc39ff271a9 04-Nov-2009 Eric Laurent <elaurent@google.com> Fix issue 2203561: Sholes: audio playing out of earpiece.

Create a new IAudioTrack interface to AudioFlinger when start() fails due to a broken pipe error.
Do the same if start fails due to the same error after time out in obtainBuffer().
Do not indicate that the AudioTrack is started to AudioPolicyManager if IAudioTrack start fails.
This avoids that an AudioTrack keeps a dead IAudioTrack after a media server crash.

Same modifications for AudioRecord.

Add a flag to ToneGenerator indicating that the callback thread can call Java. Without it, when the media server crashes and restarts, the AudioSystem error callback will crash in JNI if the IAudiotrack is created from AudioTrack callback thread.
/frameworks/base/media/libmedia/ToneGenerator.cpp
dd28d56368441537ec5eb42150516416fdbf10ad 23-Oct-2009 Eric Laurent <elaurent@google.com> Fix 2209967 Tonegenerator: mutex not release in startTone() upon timeout waiting for the stop sequence to complete.

Unlock mLock mutex when exiting upon wait stop timeout condition.
Increase timeout delays to avoid timing out when A2DP exits standby.
/frameworks/base/media/libmedia/ToneGenerator.cpp
62443f5f4517ba17d911975e695f1ab75bfdbf77 06-Oct-2009 Eric Laurent <elaurent@google.com> Fix issue 2139634: DTMF tones on Sholes popping, hissing (audio latency too high).

This change is a complement to the main fix in kernel driver for the same issue (partner change #1250).
It removes clicks sometimes heard after the end of the tones while audio flinger is sending 0s to the audio output stream.
The problem was that the sleep time between two writes was more than the duration of one audio output stream buffer which could cause some underrun.

Also fixed a recent regression in ToneGenerator that made that the end of previous tone was repeated at the beginning of current one under certain timing circumstances when the maximum tone duration was specified.
/frameworks/base/media/libmedia/ToneGenerator.cpp
af141d529f76a3e3bccf67de798f13568e37f3cf 24-Sep-2009 Eric Laurent <elaurent@google.com> Fix issue 2142613: ToneGenerator: short tones sometimes don't play on sholes or over A2DP.

When the AudioTrack callback notification size is relatively high (Which is the case on Sholes and over A2DP), it is likely that the end of tone is reached during the first callback. In this case, the AudioTrack is stopped before exiting the callback which causes 2 problems:
- 1: If the AudioFlinger thread is scheduled before we exit the ToneGenerator callback, the track can be stopped and reset before the data is actually marked as present in the buffer by the AudioTrack callback => no audio will be processed by AudioFlinger.
- 2: In this case, the data write index in the AudioTrack buffer is incremented after the track was reset by the AudioFlinger which leaves unplayed data in the buffer. This data will be played the next time the AudioTrack is started if not flushed in between.

The fix consists in adding an intermediate state to ToneGenerator state machine so that we exit the callback function when the stop condition is reached and stop the AudioTrack the next time we execute the callback.
/frameworks/base/media/libmedia/ToneGenerator.cpp
96c08a69ea0b95d1d8a8edb67f73bd9548e09f16 07-Sep-2009 Eric Laurent <elaurent@google.com> Fix issue 1992233: DTMF tones on Sholes is really long.

Add a parameter to ToneGenerator.startTone() allowing the caller to specify the tone duration. This is used by the phone application to have a precise control on the DTMF tone duration which was not possible with the use of delayed messaged.
Also modified AudioFlinger output threads so that 0s are written to the audio output stream when no more tracks are ready to mix instead of just sleeping. This avoids an issue where the end of a previous DTMF tone could stay in audio hardware buffers and be played just before the beginning of the next DTMF tone.
/frameworks/base/media/libmedia/ToneGenerator.cpp
c4e58c0f31c5044cfab0ffe80251df209844e9cc 11-Aug-2009 Eric Laurent <elaurent@google.com> Fix issue 2045983 ToneGenerator: fix void statement.

There is a void statement at line 917 of ToneGenerator.cpp: mState == TONE_IDLE;
This problem is harmless as in current code this execution path is never taken; it can only happen if a "new" operator fails in prepareWave() which is a case we usually consider as unlikely in android audio framework.
/frameworks/base/media/libmedia/ToneGenerator.cpp
a553c25b33c99b345cf1c8688f8df0ed8df14e5a 17-Jul-2009 Eric Laurent <elaurent@google.com> Fix issue 1795088 Improve audio routing code

Initial commit for review.
Integrated comments after patch set 1 review.
Fixed lockup in AudioFlinger::ThreadBase::exit()
Fixed lockup when playing tone with AudioPlocyService startTone()
/frameworks/base/media/libmedia/ToneGenerator.cpp
5964e73774b381748013b91d04dfb6fc60f533ee 09-Jul-2009 Eric Laurent <elaurent@google.com> Fix issue 1946033: dialer deadlocks and/or ANRs when using dialpad in-call

The cause is very likely that the WaveGenerator *lpWaveGen returned by lpToneGen->mWaveGens.valueFor(lFrequency) just before calling lpWaveGen->getSamples(lpOut, lGenSmp, lWaveCmd) is invalid. The frequency lFrequency is not part of the frequencies in mWaveGens.
This can happen if a different tone is started while the callback function is active: The state is changed to TONE_RESTARTING and the call to prepareWave() at line 1226 will change the tone descriptor pointed to by mpToneDesc as well as the content of mWaveGens. However, mpToneDesc was cached in a local variable lpToneDesc when entering the callback and is not reloaded when exiting prepareWave(). This causes a mismatch between the tone frequencies listed in lpToneDesc and the frequencies present in mWaveGens.
This regression was introduced in change 973 when mpToneDesc was cached in a local variable.
/frameworks/base/media/libmedia/ToneGenerator.cpp
b6d90ca1292ffab015d5068f9e184b1dc84b7233 17-Jun-2009 David Krause <david.krause@motorola.com> Fill in CDMA gaps and clean up ToneGenerator code
/frameworks/base/media/libmedia/ToneGenerator.cpp
4c9224709862c38a97c51853a93d284f55d6135d 07-May-2009 Dave Sparks <davidsparks@android.com> Don't allow negative numbers in ToneGenerator toneType parameter
Bug 1836596
/frameworks/base/media/libmedia/ToneGenerator.cpp
f3af740bdfc261b1cb25c0799af780d3753d4518 05-May-2009 Eric Laurent <elaurent@google.com> Fixed issue 1709450: Requirements for CDMA Tone Generator

Added new tone types for CDMA IS-95 specific tones.
Automatic selection between IS-95, CEPT and JAPAN version base on operator
country code for call supervisory tones.
Also improved tone generator capabilities:
- Each tone segment can now generate its own set of frequencies
- A tone does not have to be a succession of alternating ON/OFF segments
- The sequence repetition does not have to start from first segment
/frameworks/base/media/libmedia/ToneGenerator.cpp
b2a3dd88a53cc8c6d19f6dc8ec4f3d6c4abd9b54 09-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //branches/cupcake/...@137197
/frameworks/base/media/libmedia/ToneGenerator.cpp
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
/frameworks/base/media/libmedia/ToneGenerator.cpp
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
/frameworks/base/media/libmedia/ToneGenerator.cpp
15ab3eae2ec3d73b3e8aa60b33ae41445bf83f4b 20-Feb-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //branches/cupcake/...@132569
/frameworks/base/media/libmedia/ToneGenerator.cpp
da996f390e17e16f2dfa60e972e7ebc4f868f37e 13-Feb-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //branches/cupcake/...@131421
/frameworks/base/media/libmedia/ToneGenerator.cpp
d24b8183b93e781080b2c16c487e60d51c12da31 11-Feb-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //branches/cupcake/...@130745
/frameworks/base/media/libmedia/ToneGenerator.cpp
b798689749c64baba81f02e10cf2157c747d6b46 10-Jan-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //branches/cupcake/...@125939
/frameworks/base/media/libmedia/ToneGenerator.cpp
f013e1afd1e68af5e3b868c26a653bbfb39538f8 18-Dec-2008 The Android Open Source Project <initial-contribution@android.com> Code drop from //branches/cupcake/...@124589
/frameworks/base/media/libmedia/ToneGenerator.cpp
54b6cfa9a9e5b861a9930af873580d6dc20f773c 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution
/frameworks/base/media/libmedia/ToneGenerator.cpp