audioflinger: Use channel count for buffer size calculation

- For VOIP(hangout) usecase, when the ringtone is played,
  application sets flag as VOIP and the channel as stereo.
  But , on the server (audioflinger) side , the channel
  was always considered as MONO. This was leading to a
  corruption of the Cblk.
- Added changes to consider channel count in allocating the
  buffer size.

CRs-Fixed: 523984 522525

Change-Id: I160d7cf7855161efa201a86846aec67cb24d35dd

Conflicts:

	services/audioflinger/Tracks.cpp
libstagefright: support media-legacy usage

Change-Id: Ibcac0333ed4f79d71b38c26eba8cc665f2532cd0
libmediaplayerservice: fix for media-legacy usage

Change-Id: Idc6b0d9e976ece23d73ef81cebf72c4e6905647a
Add LG camera HAL parameters

Change-Id: I0a1d8c4216654abeb3de9882637ad15bc9c23dc9
libstagefright: optimize thumbnail generation path

- Checking for YUV420SP format support is not intended for software
  decoders and can be skipped. This avoids unnecessary creation of
  hardware decoders for checking supported output formats.
- Change the flag from kPreferSoftwareCodecs to kSoftwareCodecsOnly.
  This will force software codecs to be tried first and not just "prefer"
  which helps when a software codec for a particular type of codec (like
  divx) doesn't exist and avods creation of hardware codecs twice in case
  of hardware failure.

Change-Id: I682bca5b6bac5a56f46fe3655cd722fe5f08e1e6
audio: fix for deadlock issue during LPA playback

EffectModule::setEnable for LPA playback was modified to lock
AudioFligner::mLock with EffectModule::mLock held.
And at the same time ~DirectAudioTrack is trying to lock
EffectModule::mLock with AudioFlinger::mLock held and this
results in deadlock.
Fix this issue by reverting previous change and acquire
locks in certain sequence to avoid deadlock in setEnabled_l

Change-Id: Iea74eb3591a728275c655074a4d2017bd38f99ab
audioflinger: Add missing code for FM volume

 * If we used a proper MR2 audio HAL, this wouldn't be needed,
   but building FM support with the hacked up MR1 audio HAL we
   uses fails miserably. Adding this back fixes that.

Change-Id: If2f6ee9e417732eaf4df8718bf73b2dfd1062011
audio policy: Avoid unintended update of a command's timestamp

- When two setParameter calls with different keyValuePairs reach
  AudioPolicyService from HAL, the timestamp of the command received
  later is updated to that of the command received first.
  This is unintended and might cause a delay or advance the processing
  of commands.
- AudioPolicyService processes setParameters calls in the order
  in which it receives them and when two setParameter calls with
  different keyValuePairs come in (in this case, FM volume with a
  delay and routing), the timestamp of the command received last
  (routing) is updated to be processed at the timestamp of the command
  received earlier (FM volume). FM volume is set with a delay which
  causes the delay in routing as well.
- The timestamp of the command should be updated only if the
  keyValuePairs in the setParameters call match.

CRs-Fixed: 538263

Change-Id: Ie9e7d3ddf9aabd5cf551dccc27aca0a88d1edb77