* changes:
Fix bug 2201417. Whenever the System setting that indicates whether the notifcation stream uses the ring volume changes, the table of stream volume aliases in AudioService is updated. But the name of the alias stored in VolumeStreamState.mVolumeIndexSettingName was not updated whenever the NOTIFICATIONS_USE_RING_VOLUME setting was updated. This caused the wrong volume setting to be persisted. This change ensures the setting name is updated whenever the volume alias is, and persists the notification volume change right away (instead of after a delay), so that registered observers are notified right away. The notification seekbar in the sound settings is an example of such an observer.
whether the notifcation stream uses the ring volume changes, the
table of stream volume aliases in AudioService is updated. But the
name of the alias stored in VolumeStreamState.mVolumeIndexSettingName
was not updated whenever the NOTIFICATIONS_USE_RING_VOLUME setting
was updated. This caused the wrong volume setting to be persisted.
This change ensures the setting name is updated whenever the volume
alias is, and persists the notification volume change right away
(instead of after a delay), so that registered observers are notified
right away. The notification seekbar in the sound settings is an
example of such an observer.
This change forces metadata retreiver threads to background priority.
Uses an inner class to encapsulate the priority change so that it
automatically restores priority when returning to the client.
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.
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.
The problem comes from the fact that the AudioSystem callback indicating that the media server is active again is ignored if it is received before the delayed message indicating media server death. This happens if another application or service running in the system server process makes a request to the AudioSystem in the interval between the death of the media server and the reception of the corresponding delayed message.
The fix consists in resetting mMediaServerOk flags immediately when the death callback is received and not when the delayed message is received.
* changes:
Fix some metadata retriever issues: 1. mRetriever was initialized twice: one in the constructor and the other in the setDataSource 2. cached the mode so that setMode can still be called before setDataSource. mRetriever won't be initialized until data source is set; thus we have to do this
1. mRetriever was initialized twice: one in the constructor and the other in the setDataSource
2. cached the mode so that setMode can still be called before setDataSource.
mRetriever won't be initialized until data source is set; thus we have to do this
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.
* changes:
Suppress the testPing as we moved the release test target to the userdebug. This test rely on a mock_media_player.so which build under the eng build
