The headset state indicated by HeadsetObserver in the broadcast intent ACTION_HEADSET_PLUG was not 0 or 1 as specified in the java doc but contained a bit field indicating the type of headset connected.
Modified HeadsetObserver to broacast a state conforming to java doc.
Added an extra to intent ACTION_HEADSET_PLUG to indicate if headset has a microphone or not.
Removed handling of non standard headset indications from HeadsetObserver.
Removed platform specific devices from output devices defined in AudioSystem.
Modified AudioService to use new ACTION_HEADSET_PLUG intent extra instead of bitfield in state.
* changes:
Make AudioPlayer a little less verbose, defer starting audio playback until after the first video frame has been decoded (if there's video at all).
commit 08259dd3dc9026887f9bbfedaf45866eb56ea9bc
Author: Andreas Huber <andih@google.com>
Date: Thu Nov 5 12:02:31 2009 -0800
DO NOT MERGE: Use PV for metadata extraction even if stagefright is used for playback.
commit 991832fe4dc012e51d3d9ed8d647c7f09991858f
Author: Andreas Huber <andih@google.com>
Date: Thu Nov 5 11:24:11 2009 -0800
DO NOT MERGE: Do not assert if we encounter OMX_StateInvalid. All bets are off though.
commit cec45cf302d9218fe79956cbe8a462d7ca3a10bb
Author: Andreas Huber <andih@google.com>
Date: Mon Oct 26 16:11:54 2009 -0700
DO NOT MERGE: When freeing an OMX node, attempt to transition it from its current state all the way to "Loaded" in order to properly free any allocated buffers.
commit 34a1e885ef9113d68acbc26d36fcc47fdebbed84
Author: Andreas Huber <andih@google.com>
Date: Thu Nov 5 11:10:49 2009 -0800
DO NOT MERGE: Fix heap corruptin in OMXNodeInstance.
commit 5a47f7439a1298b330541a7e4e647a8b44487388
Author: Andreas Huber <andih@google.com>
Date: Thu Nov 5 11:08:19 2009 -0800
DO NOT MERGE: Fix seek-on-initial-read behaviour of OMXCodec.
commit 45bed64722501b9f411a2940aff5aff4cc4d2e98
Author: Andreas Huber <andih@google.com>
Date: Thu Nov 5 11:02:23 2009 -0800
DO NOT MERGE: Renaming string.h to stagefright_string.h to avoid conflicts.
commit 6738e306a50196f31a73d4fc7b7c45faff639903
Author: Andreas Huber <andih@google.com>
Date: Thu Oct 15 13:46:54 2009 -0700
DO NOT MERGE: Reimplement the OMX backend for stagefright.
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.
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.
* 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.
