| Age | Commit message (Collapse) | Author |
|---|
|
Commit 717e1286 introduced a regression in PlaybackThread::Track::attachAuxEffect()
when called with an effect ID of 0 to detach the auxiliary effect.
It is normal in this case that AudioFlinger::getEffectThread_l() returns 0.
Bug 6768757.
Change-Id: I7430bd1aad2f68da38f7c3e4794e7ad657bfc6be
|
|
Auxiliary effects (Reverb) are global effects and as such follow
the default rule which is to attach them to the output thread that
handles music streams by default. This causes a problem when several
threads are eligible to handle music streams as tracks can be attached
to either thread based on criteria unknown when teh effect is created.
The fix consists in moving the auxiliary effect if necessary when an
AudioTrack is attached to it and this track is not on the same
output thread.
Bug 6608561.
Change-Id: Ib32c3cabc731b2046aba728be1771982999c6069
|
|
Previously, warmup was considered done as soon as any write() took
more than 0.5 nominal cycle time. In practice, this was always the
first write() that turned on power to the output path, and it didn't
accurately account for filling the full kernel buffer queue, or for
buffering in the HAL sample rate conversion.
Now warmup is considered done when a write() _after_ the first write
takes more than 0.5 nominal cycle time.
This will throttle the initial pull rate after coming out of standby.
When combined with another change to throttle the pull rate for
devices with HAL sample rate conversion, it may help reduce some of the
notification glitches. The only downside is that it will increase the
warmup time a bit.
Bug: 6508317, 6650846, 6607056
Change-Id: I39f324c5195578170a55308e9601d3a1b41db3e0
|
|
Force a sleep if audio HAL write() returns too quickly.
Bug: 6661275
Change-Id: Ie810f5a087b89fb24dab229a0e500af1dee53571
|
|
Certain CPUs with dynamic cluster swapping and hotplug
don't report CPU frequency accurately. The file descriptors
used to read the frequency become stale and report bogus data.
So make this feature a build time option for debugging only.
This will also improve performance of the fast mixer loop.
Change-Id: I602f81ec3281a37992769208be08084ed1469e8c
|
|
Bug: 6531054
Change-Id: Iedf58e810a157aae88b5900da27c81054c437058
|
|
|
|
|
|
Change-Id: I0a3af3e2abdedebd5934f3d941d01c32cfc75e26
related-to-bug: 6647465
|
|
Don't include in FastMixer if it's not present.
This removes confusing clutter especially for devices
with a separate deep buffer output thread, or for the
duplicating thread and A2DP output thread.
Change-Id: I84933f5555593256f11ba0895ec915c09cf16963
|
|
This should help diagnose problems by allowing us to correlate
the logs with the dumpsys media.audio_flinger output.
Change-Id: I8c7c592b4f87d13b0f29c66ce7a2f301a0f063c9
|
|
Change-Id: I4ed62087bd6554179abb8258d2da606050e762c0
|
|
Add MonoPipe APIs to specify setpoint.
Use screen state to configure pipe setpoint.
Fix a long-standing bug where pipe sleep time was excessive,
which interacted poorly with governor and low clock frequencies.
Now it deducts the elapsed time since last write(),
which was significant when there was EQ and low clock frequency.
Bug: 6618373
Change-Id: I6f3b0072c2244aeb033ef0795ad164491a164ff5
|
|
The code that waits for a track presentation to be complete
before disabling it caused a regression for duplicating threads.
Because of the way output tracks activity is managed, the number
of frames output by the duplicating thread would never
reach the target set for a track to be considered presented.
The track would not be removed from active list and the thread would
not go to standby and keep its wakelock held.
Bug 6606922.
Change-Id: I4b46b420ac4cbf79a86b6791ae6589d407b01c92
|
|
|
|
Buffer more data, and return the data that is currently being
output from the audio output, to ensure that visualizations are
smooth and responsive even when the audio output has a large
latency and/or large buffers.
b/6522728
Change-Id: I401637f01be7600b3c594a55c869036c13b206c0
|
|
Do not force sleep when an overrun occurs. This was for non
blocking audio HAL and is unused.
Keep statistics on overruns.
Bug 6605215.
Change-Id: I295455d4562201aa3814c88bdd6e52c9226712af
|
|
Various fixes in direct output playback thread implementation:
- threadLoop_write() was broken for playback threads that do not
use a pipe sink.
- output buffer size calculation was hard coded for stereo.
- removed software volume that was implemented for PCM stereo
format only: the audio HAL has to implement volume if needed
for direct outputs.
Change-Id: If211b4489be9af395435707b8cf0388cce1347b2
|
|
When an audioTrack underruns, the audioflinger mixer thread
sleeps for a certain time to give the app a chance to recover.
This time is based on the reported audio HAL latency.
Some audio HALs implementing deep buffering have a variable
latency and this creates a problem if the sleep time is cached
when the output stream is opened and not updated afterwards.
This change derives the active sleep time from the mix buffer
framecount instead of the latency. This is more conservative
but works for variable latency.
Bug 6588525.
Change-Id: Ia892fc290fe06f836565c3ae15f7a2ce026c88c6
|
|
Bug: 6591648
Change-Id: Iac75e5ea64e86640b3d890c46a636641b9733c6d
|
|
Bug: 6591648
Change-Id: I696f51c682e7233ba690d97da26012084989b412
|
|
Bug: 6591648
Change-Id: Iff9cabe392bb2ce97062603adb9c9dc7aa4170d5
|
|
|
|
|
|
|
|
Bug: 6592923
Change-Id: I980c6fc69d78c569147ea44ce33a7f8a41739c91
|
|
Bug: 6580402
Change-Id: I3ac7f012062c35833147f47ba822eb4bf532a824
|
|
Now does throttling based on the requested frame count, but
still permits overfilling pipe up to the rounded-up frame count.
Also still uses the larger frame count for non-blocking arithmetic.
Bug: 6585323
Change-Id: Ic2420a071419905524a14c22ebe1ce0e32d70a9d
|
|
|
|
When an audio track underruns, the input buffer of the
corresponding effect chain (if any) must be cleared, otherwise
audio from previous mixer run will be fed again to the effect process
function.
Bug 6551652.
Change-Id: I5cd02196745f756c85af82d6937e9dc54369b37f
|
|
- Caused by already held lock in camera service
- Introduce one more lock, mICameraLock, to control access to camera
client through ICamera binder interface.
- mLock is released before calling HAL takePicture, allowing HAL
callbacks to access camera client during takePicture processing.
Bug: 5804701
Change-Id: Ibcef4857a2c844c964afefa70f9cdccdd0a55fd0
|
|
Do not refuse to create a track on an output thread if the same session
is present on another thread. It is now possible that two tracks
with the same session ID are on different threads if one can use deep
buffering and the other can't.
In this case, move effects attached to this session to the output
thread ion which the new track is created.
Bug 6530324.
Change-Id: I9019b3ee382e374c89d2319033afcfa7f886e4c4
|
|
There is an audio pipe between the normal mixer output and the fast
mixer to cope for scheduling delays and buffer size difference.
This pipe depth was not taken into account in latency calculation.
Adding the pipe contribution to the latency significantly improves A/V sync.
Bug 6520569.
Change-Id: I5584908e8aa8a02170eb38b22b4370eea800a235
|
|
Change-Id: I6b2f97881c39998a2fae9ab79d669af6c0a37e94
|
|
Change-Id: Ibff9ab62764e2acd04518a4a00e25f19e28aff4a
|
|
Trace fast track buffer fill status for underruns etc.
Move the definition of macro to Android.mk.
No overhead if disabled.
Change-Id: If0e83e21b61b059ca38f543f8a6ffb58e08c79ee
|
|
|
|
The normal mixer writes it's submix to a pipe, which is read by the fast
mixer. Now dumpsys media.audio_flinger display the raw underrun counters
when fast mixer tries to pull from the pipe but doesn't get enough frames.
Change-Id: I72505f149f9e12802784da654a651d43734e1c79
|
|
One device reports zero CPU kHz occasionally, so skip those values.
Preserve accuracy of the low-order 4 bits of the the CPU frequency.
Change-Id: I7d934f697412277462464fca82d112d0306a214e
|
|
Change-Id: I330925c7d07b6adb30b773bda3657e4efef9ae9b
|
|
When a static AudioTrack underruns, it means that playback is over.
As apps do not necessarily stop playback explicitly, AudioFlinger
should call stopOutput() to decrease activity ref count in
audio policy manager.
Bug 6486311.
Change-Id: I1ea722c443780329ded6310c958b24726e918d16
|
|
- Added a timeout in case the trigger event is never fired.
- Extend AudioRecord obtainBuffer() timeout in case of
synchronous start to avoid spurious warning.
- Make sure that the event is triggered if the track is
destroyed.
- Reject event if the triggering track is in an incompatible state.
Also fix a problem when restoring a static AudioTrack after
a mediaserver crash.
Bug 6449468.
Change-Id: Ib36e11111fb88f73caa31dcb0622792737d57a4b
|
|
The video playback engine depends on having relatively precise audio
progress updates for its A/V sync and frame drop calculations. For small
audio HAL buffer sizes, this was not a problem, but when the HAL buffer
size was > 12 ms, the normal mix buffer size became > 24 ms and this
then caused video problems. The new formula tries to keep the normal
mix buffer size within a closer tolerance of 20 ms to 24 ms.
Also use consistent term: multiplier instead of multiple.
Bug: 6479613
Change-Id: I903bad74461908e8c8f0a61e99ab5e24d5c44433
|
|
Maintain more accurate accounting of type of underrun.
Automatically remove track from active list after a series of "empty" underruns.
Change-Id: If042bf80e1790dcaaf195c99dc9c0ed9b55382c1
|
|
Previously, the state of a fast track "wiggled" back and forth at the end.
Now it goes through these transitions:
active -> stopping_1 -> stopping_2 -> stopped
This CL is only for fast tracks, and does not change how
normal tracks work.
Change-Id: Icc414f2b48c46dda63cfa6373ca22d033dd21cd4
|
|
Audio effects on the output mix should not be suspended when effects
on the output stage (post processing) are enabled.
Change-Id: I2e1c08fa9358ea3cbaec68856738d504b1be54e4
|
|
Was losing the upper half of the bounds, and MHz was off.
Change-Id: I61c98027b35ce7c3578ea6f3acf05aa5c48a5831
|
|
Disabled by default; uncomment ATRACE_TAG to enable
Change-Id: I99af894022a859ee5644bd853cfd8a48e4735ff9
|
|
Compute statistics on fast mixer elapsed time and CPU load per cycle using a
simple moving average rather than by fixed blocks. This has a couple advantages:
- remove burstiness of CPU usage due to former floating-point calculations in fast mixer
- gives us flexibility in how to report (e.g. could report over just the last 1 second)
Disadvantage is increased RAM, and since the samples are not updated
atomically, it is possible to have an error in the statistics. This
should not be much of an issue due to the relatively large number of samples.
Also add CPU raw ns and adjusted MHz statistics.
Change-Id: Iaa2cd13f18250c3162aff40409b3694b769d9505
|
|
Previously displayed TrackBase::mFrameCount but not control block frameCount.
Now displays both.
Also display the track flags in control block.
Change-Id: Ie53781d4784633d78b6f928d69ebd494d8f110ec
|
