commit 4abf16bb04dc9695fedf4007a84f903074312ccd
Author: Andreas Huber <andih@google.com>
Date: Tue Jul 20 09:21:17 2010 -0700
Support a single format change at the beginning of audio playback. This way the AAC+ decoder may change its output format from what is originally encoded in the audio stream and we'll still play it back correctly.
Change-Id: Icc790122744745e9a88099788d4818ca1e265a82
related-to-bug: 2826841
commit 09c74da63e6ad5cb5dafb70f62696d75d2978967
Author: James Dong <jdong@google.com>
Date: Sun Jul 18 17:57:01 2010 -0700
Fix MPEG4Extractor to extract sampling frequency correctly when SBR is enabled.
Change-Id: I883c81dad3ea465e71cb5590e89d763671a90ff8
commit f672bf2a782dc7d5fb6325d611a7fe17045dfe9a
Author: James Dong <jdong@google.com>
Date: Thu Jul 8 20:56:13 2010 -0700
Enable the support for decoding audio with AAC+ and eAAC+ features
bug - 282684
Change-Id: I73c8377af3cc4edd3ee7cea86dc3b1c369fbd78b
Change-Id: I012f1179e933b6d1345d2368f357576c722485f7
Problem:
When the bluetooth device is removed, the AudioService clears all active SCO connections
and unlinks from the client application's binder interface death.
The problem is that the unlinking is done even if no more connections are active for a given client,
which throws a runtime exception that is not catched causing the system server to crash.
The fix consists in calling unlinkToDeath() in ScoClient.clearCount() only if the number of
active SCO connections for this client is not 0. The NoSuchElementException exception is also
catched when calling unlinkToDeath()
Change-Id: I7086424301fc63a5666da61c38169349d3e078f4
having it inherit its priority from the thread that created it is a bad idea.
Instead, set the priority explicitly, and bump it to slightly higher than normal.
Change-Id: I01843f24905790ce2e2cde5d11a99346cfbf968d
Change-Id: I576178144ffd753b809e1c4ae269ffc3aa34b511
related-to-bug: 2686604
QA-Impact: well, ..., everything related to streaming mpeg4/aac content over http
Specify a response header of "X-SocketTimeout: 15" to override the default timeout
of 5 secs with a timeout of 15 seconds. Specify a negative value to disable the
timeout altogether.
Change-Id: I545adf3d8b3f7efe5f8d081a641c6404440a77db
related-to-bug: 2675721
When the user selects a "Silent" notification sound, the Uri encoded
path is an empty string. Setting this Uri as the data source of the
MediaPlayer used to play notifications caused the completion listener
to not be called, which with the AudioFocus logic causes the Music
app to pause and never resume. The NotificationPlayer modifications
cause the MediaPlayer for the notification to only request audio
focus when the data source is not empty.
The audio focus code in AudioService is defensively synchronized
against a unique lock, and the exception observed in bug 2670395
is explicitely caught in case another edge case wasn't caught by
this fix.
The AudioFocus handling in AudioManager is modified so only the
requestAudioFocus and abandonAudioFocus methods are meant to be
used, as registerAudioFocusListener and unregisterAudioFocusListener
provided no additional functionality over the request/abandon
methods. abandonAudioFocus() also removes the listener from the
map in AudioManager since after abandonning focus, the listener
would no longer be called.
Change-Id: I3b553ee8a8163c25e01117d7e5479dd5fdfa7c6b
Set the magic property media.stagefright.enable-vorbis to true to use the new implementation instead of the standalon vorbis player for file-based playback. HTTP streaming of vorbis content will always go through stagefright.
Change-Id: Ie3843a99fadb22372f89540d0f8d65196e0c2af8
related-to-bug: 2654400
Hardware MP3 decoder could lead to hang in the Music application, although the chance is very low.
bug - 2608400
Change-Id: Ia0b5b6521015fc8d3e086117fa914dcc20ace5bd
connected to A2DP media profile
When the phone is docked and using the dock A2DP, and the user
connects another A2DP device, make the dock unavailable immediately
before connecting the new A2DP device.
Change-Id: I82d53836fb509ee4ea7cdb68f467dfb946c634f8
Phone calls and rings are treated as a new client, with a dedicated
client ID that identifies it in the audio focus stack. When it is
present in the stack, others clients cannot request audio focus
(request is denied).
Because the phone state is now mostly handled like a new client,
there is no need monitor mode changes and to keep track of
undispatched focus changes, as those will delayed focus gains
will now automatically happen at the end of the call when the
phone client is removed from the focus stack.
Change-Id: I11ff73b015ab93f07040755fd8ee75c8d675e025
This currently only applies to the component OMX.TI.AAC.decode, it is the only one to support coalescing in the first place.
In certain edge cases (encoded audio track contains silence), each buffer would turn out to be an amazing 6(!!!) bytes, we'd spend lots and lots of time streaming network data to fill the codec's buffers of size 6144 bytes with .. silence.
Change-Id: I9f449f310fc64ca384bd02e4a783e33cf5b46fcc
related-to-bug: 2609049
QA-Impact: streamed (http) playback of aac audio content on Droid.
the is_music, is_ringtone, etc columns. This ensures that custom
ringtones will still be shown in the ringtone picker after a rescan.
Bug 2594125
Change-Id: I56761240d6f6e699514169d80a445317ba0de9e2
The problem occurs if the device is powered down in silent mode. When the device restarts,
AudioService reads current ringer mode from saved settings but does not call setRingerModeInt()
to perform actions required when ringer mode changes.
The volumes of streams affected by ringer mode are actually at 0 because they are also read from settings
but their mute state is not applied correclty. When we later exit from silent mode, the streams
other than STREAM_RING that are affected by ringer mode are not restored as they are not considered
muted. This applies to STREAM_SYSTEM but also to STREAM_NOTIFICATION if its volume is controlled independently
from STREAM_RING.
The fix consists in calling setRingerModeInt() when AudioService starts.
Change-Id: Ica75b9874938dda1bc1b634c3e97db4a650d295c
There was a regression introduced by change 4c637b9e34f4c8db69a64ad21a4e2bcfa7485b5f
fixing issue 2578813. As the A2DP device disconnection is notified to the audio policy manager
after a delay, there is a period during which the A2DP device is actually not connected but the
A2DP output is considered present by audio framework. If a playback is started during this period,
The A2DP output requests the activation of the A2DP sink which in turn triggers a reconnection
of the A2DP sink.
The fix consists in suspending the A2DP output immediately when receiving the A2DP disconnection
intent so that any activity on A2DP output is ignored until the output is actually closed by the
audio policy manager.
Change-Id: I16eaace45e12bfc970f50836b46a73b756b493f0
This is a regression introduced by change 5b4e654d0c7de8e4d58d73e73b0d5220f19b68f7 for issue 2472495.
When AudioService changes audio mode, setMode() reapplies current volume for the default active stream
which in this case is STREAM_RING.
Because the new implementation of silent mode actually mutes the ringer stream,
setStreamVolumeInt() now applies the volume change received while in silent mode
to the last audible value and we end up clearing the last audible volume for ringer.
The fix consists in not modifying last audible value when the new value is 0.
Also removed obsolete code in setStreamVolumeInt() since new implementation of setRingerModeInt()
in change 5b4e654d0c7de8e4d58d73e73b0d5220f19b68f7.
Change-Id: I746f3bc1af39a602ce12d130ce592007b2d0ebb6
The problem happens only if volume down key is pressed while
already in silent or vibrate mode. In this case, AudioService accepts
changing the last audible index for ringer volume from 1 to 0.
When volume up is pressed, current ringer volume value is restored from 0
instead of 1.
The fix consists in keeping last audible index at 1 once in silent of vibrate
mode even is volume down key is pressed.
Change-Id: Id08edd12ce985c22233124545eba2c3e4b8cdc8e
