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
frameworks/av: Fixed framecount in AudioRecord

- Incorrect frameCount is passed to AudioRecordClientProxy,
  which is used while user side pointer is incremented
  This is causing distortion in SIP call
- Fix is to use frameCount of the shared block instead of
  frameCount passed by the client
- InputBytes initialization is also done in AudioFlinger

Change-Id: I4470be49c44e0c86c8a6262f57cabbc609c32045
Crs-fixed:  525315
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
Merge "audio policy: Avoid unintended update of a command's timestamp" into cm-10.2
camera: Remove deprecated QCOM camera hacks

Change-Id: If48c5b7c904d26ec2a8307fa690f983660fd7b5a
CameraClient: Enables meta data notifications

- Adds the needed functionality for enabling/disabling
  metadata messages depending on the camera client
  commands.

Change-Id: Iab597d5519b8fb85ee21c824ec19e9aaec9b5219
CameraService: Adds support for longshot mode

- This change introduces additional functionality inside
  CameraClient for supporting continuous compressed data
  callbacks. This is needed for 'Burst/Long shot' mode
  where we could have indefinite number of callbacks after
  capture is triggered.

CRs-Fixed: 514199
Change-Id: I8b155e305a836729b071e5388a7046c6347bb9f3
camcorder pause feature

--libmedia: add pause() interface in MediaRecorder and IMediaRecorder and add Pause state in mediarecorder's state machine
--libmediaplayerservice: add pause() interface in MediaRecorderClient and StagefrightRecorder
--libstagefright:      1.stop-in-pause implementation in recording pipeline for pause feature;
--camerasource: support switch between start() and stop()
--audiosource:  support switch between start() and stop()
--soft aacenc component:  clear some variables when doing flush to support re-start
--soft amrnbenc component: clear some variables when doing flush to support re-start

Change-Id: I3036ef8f4cc7644c1d36aa0b19e64fc9dc12c1f8
Camera: Dont process dataCalllback if recording is stopped

Issue: Here stopRecording is not finished as the previous
recording frame process has not completed. dataCallbackTimeStamp()
in CameraSource.cpp has stuck in the thread itself waiting for a lock.
In between, reset() function in CameraSource.cpp has called
and acquired lock. Reset() function calls stopRecording.
So the dataCallbackTimeStamp() is continuously waiting.
Unless dataCallbackTimeStamp returns, processRecordFrame
in HAL will not finish.

CRs-Fixed: 518351

Change-Id: I19bbdb4b50b0113a419c9229f0e26c56e8ce91e8
Merge remote-tracking branch 'cm/cm-10.2' into jb-4.3