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
Applications can use this API to estimate the distance
between the subject and the camera.
bug:1955650
Change-Id: Ie6c8ea4971759cab6c9bcdda2c5ceb5925791c27
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
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
Merge commit '900b6157f5dee2ed7b2c73cf320b2baf293230ff' into kraken
* commit '900b6157f5dee2ed7b2c73cf320b2baf293230ff':
Only hold a weak pointer on SurfaceComposerClients
Some variables and structure members should be renamed to reflect the fact that they contain the
number of channels in a track (channel count) or the actual channels used by a track (channel mask).
Especially member "channels" of track control block (struct audio_track_cblk_t) is actually the
number of channels (channels count).
Change-Id: I220c8dede9fc00c8a5693389e790073b6ed307b8
the new TextureMagager class now handle texture creation and upload
as well as EGL image creation and binding to GraphicBuffers. This is
used indirectly by Layer and directly by LayerBuffer
the new BufferManager class handles the set of buffers used for a
Layer (Surface), it abstracts how many buffer there is as well as
the use of EGLimage vs. regular texture ops (glTexImage2D).
Change-Id: I2da1ddcf27758e6731400f6cc4e20bef35c0a39a
this hack was used for gpus that don't support cached buffers
for s/w clients. currently we have no gpu with this issue.
this removes quite a bit of complexity.
Change-Id: I72564669f124f92805030e61983711f61c76b6d9
