The problem is due to a too big difference between the buffer size used at the hardware interface and at the A2DP interface.
When no resampling occurs we don't notice problems but the timing is very tight. As soon as resampling is activated, the AudioTrack underruns.
This is because the AudioTrack buffers are not resized when moving the AudioTrack from hardware to A2DP output.
The AudioTrack buffers are calculated based on a hardware output buffer size of 3072 bytes. Which is much less than the A2DP output buffer size (10240).
The solution consists in creating new tracks with new buffers in AudioFlinger when the A2DP output is opened
instead of just transfering active tracks from hardware output mixer thread to the new A2DP output mixer thread.
To avoid synchronization issues between mixer threads and client processes, this is done by invalidating tracks
by setting a flag in their control block and having AudioTrack release the handle on this track (IAudioTrack)
and create a new IAudioTrack when this flag is detected next time obtainBuffer() or start() is executed.
AudioFlinger modifications:
- invalidate the tracks when setStreamOutput() is called
- make sure that notifications of output opening/closing and change of stream type to output mapping are sent synchronously to client process.
This is necessary so that AudioSystem has the new stream to output mapping when the AudioTrack detects the invalidate flag in the client process.
Previously their were sent when the corresponding thread loop was executed.
AudioTrack modifications:
- move frame count calculation and verification from set() to createTrack() so that is is updated every time a new IAudioTrack is created.
- detect track invalidate flag in obtainBuffer() and start() and create a new IAudioTrack.
AudioTrackShared modifications
- group all flags (out, flowControlFlag, forceReady...) into a single bit filed to save space.
Change-Id: I9ac26b6192230627d35084e1449640caaf7d56ee
Merge commit 'c7388e3541c9f1d64dd13fc2de49ff77d8993fa5' into kraken
* commit 'c7388e3541c9f1d64dd13fc2de49ff77d8993fa5':
Make the SSID field of WifiConfiguration consistent with API description.
Merge commit '5f1beda18fc7709c2e61ace33607513770faf115' into froyo-plus-aosp
* commit '5f1beda18fc7709c2e61ace33607513770faf115':
Make the SSID field of WifiConfiguration consistent with API description.
Applications can use this API to estimate the distance
between the subject and the camera.
bug:1955650
Change-Id: Ie6c8ea4971759cab6c9bcdda2c5ceb5925791c27
Merge commit 'a5cd816c720ed87b91a33aa5d000a0d308c74453' into kraken
* commit 'a5cd816c720ed87b91a33aa5d000a0d308c74453':
Fix sampleTable instantiation, this makes sure that the sample table refers to the custom datasource that caches the metadata to prevent needless seeking.
It no longer makes sense to create type info from Java since this
cannot be exported to scripts. The new flow is in the opposite direction.
Change-Id: I9b46e3f57abf84c01326bd9b9b834f3ff0f7c504
Merge commit 'eb9128f9b0ee660504621381fd96f82d5bf8a3fd' into froyo-plus-aosp
* commit 'eb9128f9b0ee660504621381fd96f82d5bf8a3fd':
Fix sampleTable instantiation, this makes sure that the sample table refers to the custom datasource that caches the metadata to prevent needless seeking.
Change-Id: I576178144ffd753b809e1c4ae269ffc3aa34b511
related-to-bug: 2686604
QA-Impact: well, ..., everything related to streaming mpeg4/aac content over http
Its possible that during a resize the EGL information could be stale so
caching this is bad. The surface size should always be correct.
Change-Id: Ifd479e1ea70b1cada1a8690c7c82e91aa391b685
Conflicts:
libs/rs/rsProgramStore.cpp
libs/rs/rsProgramStore.h
