Fix for bug 6446715
Fix a deserialization bug which was causing an assertion failure in
stagefright and bringing down the entire media server. Basically, you
will hit this any time you play a track longer than ~2147 seconds.
(Technically, the crash will happen any time the play pointer at a
position which is ~2147 * (1 * 2N) where N >= 0)
Change-Id: Ic0d371b0f6c29fddf0a033f5de08a70b3e63c854
DO NOT MERGE
Change the AAH_RX player so that it implements MediaPlayerHWInterface
(instead of just MediaPlayerInterface) so the app level can control
the rendering volume of individual RX player instances as well as the
stream type of the audio tracks created by the RX player.
Change-Id: Ieff1ea774f7981227546744883ee4b4e87a2cd2a
Signed-off-by: John Grossman <johngro@google.com>
Some products manipulate only the master volume, and the existing
code does not play volume-change tones when the master volume
is adjusted. This CL includes some config-driven behavior that
will play those tones (via the system stream) if desired.
Bug 6498986
Change-Id: I2415773325d0a0039efc67897bc371b1f2e18063
This lets us avoid a Binder roundtrip to the system process during
volume changes. Previously volume change would be staged at key-down,
then applied at key up in tandem with playback of the sonic feedback
about volume key presses. The reason for this two-stage handling was
to defer playback of the sound [at the target volume] while the volume
key was being held for repeat.
On some devices volume is always sent as key down/up pairs rather than
down-repeat-up sequences. On these devices it is more efficient to
apply the new volume immediately during down handling, and have the
up handling be a no-op. This CL adds a configuration resource item
selecting this new fast path.
Bug 6433943
Change-Id: Icffa56e958243b841d514e2fe4609ba3a7b20f14
Adds flag argument to setMasterMute. This allows third parties to edit it
without showing the UI, for example.
TESTED = runs on Tungsten.
Change-Id: Idfd99a2476e60059cd93c9dfe07d03a389c3f5f5
Broadcast mastervolume intents regardless of whether the system changed the
volume. This fixes the bug where the volume LEDs stop getting updates.
TESTED = runs on Tungsten.
Change-Id: Id363da3f825934fd7785ed3d3e436f74e657b7e6
Immedately release any TX group a player is holding upon entering the
error state. Once in the error state, the only way out for a media
player it to be completely reset (destroying the player at the
tx_player level of things). There is really no point in holding on to
a tx group once the player is in the error state.
Change-Id: If5442a32e012b5596789078b0790ed73fa842629
When an audio decoder signals a format change, we were destroying our
renderer so that a new one could be created with the new format, but
we were not updating our internal format state variables with the new
format information.
This fixes issues with AAC audio with SBR extensions; in particular
content coming from Pandora. Pandora audio is currently being
delivered as AAC-LC decoding to 22.05 KHz, but with an SBR layer which
gives 44.1 KHz. Whether or not you are going to get 22.05 or 44.1
depends on if your decoder supports SBR ("High Efficiency" profile).
Stagefright does not parse the extension sample rate present in the
ESDS; instead it reports the sample rate of the base stream (22050 in
this case). Its only when the decoder decides it can handle SBR that
you get a chance to discover that the content is actually 44.1,
information it delivers via a format change status code during read.
Signed-off-by: John Grossman <johngro@google.com>
Change-Id: I78fb89b4356004d7834629ccc82ca99c4cc7954a
Fix a mistake which came in as part of a merge conflict resolution
during code review of the recent unicast mode refactor of LibAAH_RTP.
Nop packet which were supposed to carry TS transformations for the
pause state accidentally got flagged as Flush operations. The flush
packet successfully carried the TS transformation, but also had the
undesired side effect of constantly flushing the stream.
Change-Id: I4c6aa0043fc274a1d7e880ed1d19cf277f22194b
Signed-off-by: John Grossman <johngro@google.com>
EOS was being treated as a flush operation which was causing problems.
In particular, the transmitter was delcaring that playback was
complete early (by the clock lead time of the system, which was 1
second in this case). Also, the receiver was treating the EOS message
just like the flush message, immediately destroying the substreams
associated with the program without letting them play out first.
Change the transmitter to send the EOS message like it always does,
but have it wait until the media time of the last sample has arrived
before reporting playback complete to the app level of things.
On the receiver side of things, don't treat the EOS message like the
flush message. Instead, have the EOS message simply put the substream
into EOS mode, allowing it to signal EOS to its decoder and shut off
the isAboutToUnderflow hack.
Change-Id: Ibe3ac01044373f83edb7a5f4b70478bd78c16d11
Bionic/Android support eventfd, so there is really no reason to have
PipeEvent around any more. This change gets rid of it in LibAAH_RTP
and replaces it with eventfds.
Change-Id: I841fcb71bf5015d521d7517c69f44eac0ea92278
Signed-off-by: John Grossman <johngro@google.com>
Add support for unicast mode to the AAH RXPlayer. At the API level,
things should be pretty simple. To use unicast mode, instead of
passing the multicast address and port in the data source URL, just
pass the unicast address and port of the transmitters command and
control port. For example, instead of
aahRX://224.128.60.5:8867
one might instead pass
aahRX://192.168.63.5:55476
Change-Id: I7b40716983d7a91def86dcf40f093dda4255aae3
Signed-off-by: John Grossman <johngro@google.com>
Fix a bug discovered while working on adding unicast mode to the TX/RX
players. Also some general cleanup/consolidation regarding timeout
code.
The bug went like this. When a TX player had hit EOS, it would send
an EOS command payload to its receivers. Later, when application
level code shutdown and cleaned up the player, it would send another.
In situations where there is massive packet loss, there is a chance
that not only did both of the EOS packets get dropped, but that they
never got filled in by the retry algorithm because the receiver gave
up on the RTP gap due to an aboutToUnderflow situation in at least one
of its active substreams.
When this happens, there are two major problems. First, all of the
substreams associated with the TX player which has now gone away have
become effectively leaked. They will only get cleaned up if the
entire RTP stream (the TX Group) goes away for 10 seconds or more, or
when the RX Player itself is reset by application level code or a
fatal error. These substreams are holding decoder and renderer
resources which are probably in very short supply, which is a Bad
Thing.
Second, there is now at least one substream in the RX player which is
never going to receive another payload (its TX player source is gone),
but is still considered to be active by the rx player. Assuming that
this substream's program was in the play state when the track ended,
there is now at least one substream which is always
"aboutToUnderflow". From here on out, when the retry algorithm is
attempting to decide whether or not it has the time to attempt to fill
in a gap in the muxed RTP sequence, it always decides that it does not
have the time because of the orphaned substream which is stuck in its
about to underflow state. This effectively means that the retry
algorithm is completely shut off until the rx player gets reset
somehow (something which does not happen during normal operation).
Since the environment had to be extremely lossy to trigger this chain
of events in the first place, and its probably no better now, your
playback is just going to be chock full of gaps which produces
horrible stuttering in the presentation stage of the system.
Two new failsafes have been introduced to keep the double EOS drop
from causing this. First, a timeout has been introduced on the
substream level, in addition to the already existing RTP level
timeout. If a substream fails to receive an activity for 10 seconds
(same timeout as the master RTP timeout), it will be automatically
flushed and purged.
Second, the nature of the master RTP timeout on the transmitter side
has been changed. Instead of just sending an empty NOP command packet
to indicate that the main RTP stream is still alive, the transmitter
now sends a new time of command packet; the Active Program Update
packet. This packet contains a list of all the active program ID
attached to this TX group. Upon receiving one of these APU packets,
RX players reset the inactivity timers for all substreams which are
members of the programs listed in the packet, but they also
immediately purge any substreams associated with programs not present
in the APU.
Between the two of these, no matter how nasty and selective the packet
smashing gremlins in your system happen to be, substreams will always
eventually clean up and avoid getting stuck in a perma-stutter
situation.
Also in this CL:
+ Extract some common utility code into a utils.cpp file so that it
can be shared across the library.
+ Stop using custom timeout logic in the RXPlayer. Instead, use the
common Timeout helper class in utils.cpp.
Signed-off-by: John Grossman <johngro@google.com>
Change-Id: I350869942074f2cae020f719c2911d9092ba8055
Significantly refactor the TXGroup code to allow transmit groups to
operate in a unicast fanout mode in addition to the traditional pure
multicast mode. Important changes include...
+ Each transmit group active in the system now has its own socket to
send and receive traffic on. In the past, this socket was used to
listen for retry requests from clients. Now it is also used to
listen for group membership reports (IGMPv3 style) from unicast
clients. Having an individual socket per transmit group allows
unicast clients to join the group needing only the IP address and
port of the transmitters socket, and not needing any additional
"group id" to be sent to the client beforehand.
+ Setup for the transmitter is now slightly different. As before, to
setup for multicast mode, a user can call setRetransmitEndpoint
passing an IPv4 multicast address and specific port to transmit to.
It used to also be the case that a user could pass a specific
unicast address and port to transmit to as well. This is no longer
allowed. Instead, to operate in unicast mode, a user passes 0.0.0.0
(IPADDR_ANY) as the IP address. In addition, they need to pass
either 0 for a port to create a new unicast mode TX group, or they
need to pass a specific port to cause the player to attempt to use
an existing unicast mode TX group. The specific port should be the
command and control port of the TX group which was bound to when the
group was originally created.
+ A magic invoke was added to allow clients to fetch the command and
control port on which a TX Player's TX Group is listening.
The API described above is most likely temporary and should eventually
be replaced with one where TX groups are formal top level objects with
their own independent interface and life-cycle management.
Signed-off-by: John Grossman <johngro@google.com>
Change-Id: Ib4e9737c10660d36c50f1825c9824fff5390b1c7
Rename AAH_TXSender to AAH_TXGroup in preparation for refactoring to
support unicast retransmission.
Signed-off-by: John Grossman <johngro@google.com>
Change-Id: I3984db27d1c61c6155d5d7cb9c38eead421b9249
The AudioSink latency is currently cached when the associated AudioTrack
is created. However, the AudioTrack latency can change if the AudioTrack is moved
from one output stream to another.
The AudioPlayer must also periodically update its view of the latency
as it is needed to compensate the real audio time used for A/V sync.
This fixes an A/V sync problem seen when switching A2DP on and off while
playing a video.
Change-Id: I28b24049ca114e1af3e24791dcc900f463536ba4
Conflicts:
media/libmediaplayerservice/MediaPlayerService.cpp
Current AudioTrack implementation enforces that the requested audio
buffer size is at least corresponding the audio latency.
This requirement is too strong and leads to problems with current
stagefright and AudioSink implementations when playing over output
streams with long latency.
Ultimately, the AudioSink design should be changed to specify a minimum
buffer size in time or frames units but not in buffer count units.
Change-Id: I8ba603956f92ac49143a8249572665aa548f2f0f
Conflicts:
media/libmedia/AudioTrack.cpp
Move in the direction of a more publishable API for configuring a
media player for retransmission. It used to be that we used a custom
invoke and a modified URL (prefixed with aahTX://). There are many
issues with this technique and it was never meant to stand the test of
time.
This CL gets rid of all that. A new (but currently hidden) method was
introduced to the java level MediaPlayer API, called
setRetransmitTarget(InetSocketAddress), which allows an app writer to
set the retransmit target. For now, this method needs to be called
before a call to setDataSource (which is pretty unusual for the
MediaPlayer API) because this mid level code uses this as a cue to
instantiate an aahTX player instead of relying on the data source to
select a player. When retranmit functionality becomes part of the
existing android player implemenation, this
set-retrans-before-set-data-source behavior can go away, along with
the aahTX player itself.
Change-Id: I6ab07d89b2eeb0650e634b8c3b7a0b36aba4e7dd
This reverts commit 64006cb1642b2ec0ee74c66007d869b884391fd1.
Back out this change in order to get ready to implement a longer term,
more media-team approved way of selecting a retransmit player.
Change-Id: I97b68b9859a174eab858598cb00d4445a14fbc17
Change the CCHelper class to be an instanced instead of a static
pattern. The CCHelper instances all share an interface to the common
clock service and register/unregister a callback handler in response
to there being CCHelper instance in the system or not. This brings
usage of the CCHelper into like with the new auto-disable
functionality of the common time service. For any given process,
whenever there are CCHelper instances active, the process will
maintain a callback target to the common clock service and will be
considered to be an active client.
Also change all of the users of the CCHelper interface to manage the
lifecycle of their new CCHelper instances.
Change-Id: I7c28c5d70d9b07ba7407b4ac706e7e7d7253001b
Bulk name change to remove references to Android@Home from the common time
service in preparation for cleanup and up-integration into the master
branch. Basically, aah_timesrv is now common_time.
Change-Id: I3d3db212f96e8ba171aa36b9c58e27e4a336cb0a
* Added a MediaPlayer.setMediaPlayerType API that be called to specify the
desired media player implementation before calling setDataSource
* Implemented setDataSource(fd) in the AAH_TxPlayer
Change-Id: I359075d9c7d6fd699dda14eb85ec50da19307639
