Merge commit 'bf96aaadd46fb5b0884070177faa16ec4f22e2ba' into eclair-mr2
* commit 'bf96aaadd46fb5b0884070177faa16ec4f22e2ba':
Fix issue 2192181: AudioFlinger must provide separated methods to set VOICE_CALL stream volume and down link audio volume.
Also DataSources now must provide a method initCheck()
and DataSource::reat_at has been renamed to readAt to conform to
standard API naming guidelines.
While our hardware decoders clearly outperform the software decoders in terms
of raw throughput, their startup latency makes them less suitable for thumbnail
extraction.
Added setVoiceVolume() method to AudioSystem, AudioFlinger, IAudioFlinger, AudioPolicyService.
Removed call to AudioHardwareInterface::setVoiceVolume() from AudioFlinger::setStreamVolume().
Add a quirk mode to OMXCodec that makes it aware of this fact for proper display. Also integrate back a change from eclair-mr2 that delays releasing an output buffer briefly after posting it to surface flinger, as we don't know how long it'll take it to actually display the buffer's content.
Besides a major cleanup and refactoring, OMX is now a singleton living in the media server, it listens for death notifications of node observers/clients that allocated OMX nodes and performs/attempts cleanup.
Changed APIs to conform to the rest of the system.
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.
This currently assumes 44k stereo (won't crash on other formats, but won't give the correct results either), and links statically with libspeex to get FFT data, increasing the size of libmedia by about 45kb.
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.
This api allows to instantiate a renderer by specifying the hosting java Surface object. This hides the implementation details of (java-)Surface, (native-)Surface and friends.
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.
* changes:
When encountering a .nomedia file, notify the MediaScannerClient, so that it can erase the data column for entries that are in the folder containing the .nomedia file. This prevents us from deleting (via a delete trigger) files when somebody adds a .nomedia file after the fact.
so that it can erase the data column for entries that are in the
folder containing the .nomedia file. This prevents us from
deleting (via a delete trigger) files when somebody adds a
.nomedia file after the fact.
commit c45bfbb97ccd05982008df47181f9c73abaf0497
Author: Andreas Huber <andih@google.com>
Date: Tue Sep 1 15:58:12 2009 -0700
This quirk should not be enabled by default in order to make the bug reproducible by the vendor.
commit 21d72e80e795fcae53d9c3bcc8ba6312b081e420
Author: Andreas Huber <andih@google.com>
Date: Tue Sep 1 15:55:45 2009 -0700
Undoing the hack to temporarily give up the lock to facilitate reading from the buffer source.
This simply causes too many issues, there need to be independent threads providing input buffers and dequeuing output buffers.
commit 84d507def8999c146ce124cc8edfe106c9ca70c2
Author: Andreas Huber <andih@google.com>
Date: Tue Sep 1 15:16:23 2009 -0700
The AAC components appear to output stereo data even if the input data is mono...
commit 3fa5f3ce910f34da0cedb8bcce1bd593db7eb740
Author: Andreas Huber <andih@google.com>
Date: Thu Aug 27 14:48:54 2009 -0700
Getting rid of more code now obsolete with the departure of OMXDecoder.
commit e0d923ec0c7bb60bec8eb97739036a4c70c0feef
Author: Andreas Huber <andih@google.com>
Date: Thu Aug 27 14:33:06 2009 -0700
Remove obsoleted OMXDecoder class. OMXDecoder is dead, long live OMXCodec.
