The caller could use it to check whether frontend status is ready to
read or not.
Bug: 171540820
Test: atest VtsHalTvTunerTargetTest
Change-Id: I65521aacd8afe824342ad0b24f7d89006ceb5851
The startTime needs to be set before setting the delayHint timeout as
that is when the callback scheduler's clock start ticking.
In addition, we need to await the first callback before starting the
test to make sure the scheduler thread has been run at least once (so
the timeout should be initialized correctly).
Test: atest TunerFilterAidlTest#FilterDelayHintTest
Bug: 210943300
Change-Id: I0b2443f3e7d33977fb6666ba09d3ff51d8b1f152
*) Clarify the meaning and unit of FrontendStatus.
*) Add comment for STC ready support.
*) Support for control signal (e.g. TMCC) change monitoring
Bug: 183634950
Bug: 202247846
Bug: 183630794
Test: Make
Change-Id: I3c48993c354e865b0edfe56adbd34c7fce120efc
*) Add DTS info to DemuxFilterMediaEvent.
*) Allow to ignore download Id in DemuxFilterDownloadSettings and put
download id into DemuxFilterDownloadEvent.
*) Support dumpsys.
*) Change section data size 64 bits.
*) Support FrontendStatus streamIdList.
Bug: 183583908
Bug: 183024067
Bug: 184017033
Bug: 203181023
Bug: 171540818
Test: atest VtsHalTvTunerTargetTest
Test: atest android.media.tv.tuner.cts
Test: dumpsys android.hardware.tv.tuner.ITuner/default
Change-Id: I7478d008fc50da6700c551ae398dca15f8b350be
The VTS can be configured by adding timeDelayInMs and dataDelayInBytes
attributes to the VTS configuration's filter tags (as long as the filter
is not a media filter (media filters do not support FilterDelayHints)).
In order to circumvent a FilterDelayHint race condition around
configuring the hint (where the internal condition variable is notified
when the delay hint changes. If the scheduler thread has not been
scheduled to run before adjusting the delay hint, and callbacks are
added right after, they are always sent out immediately (as the cv predicate
still returns true when it is first evaluated after adjusting the delay)).
Test: atest VtsHalTvTunerTargetTest
Test: atest android.media.tv.tuner.cts
Bug: 183057734
CTS-Coverage-Bug: 209593343
Change-Id: I1b0893afce262b18ee385ec0f384e6ceebf58c7d
This fixes multiple issues in filter callback scheduler:
- currently, when mDataSizeDelayInBytes is 0, filter events are sent
every time onFilterEvent is called. When mTimeDelayInMs is set (to
something else than 0), this will falsely override the time delay.
- when datasize delay or time delays are updated, the cv needs to be
notified so the new delay goes into effect right away.
- std::condition_variables *must* make use of a shared variable in order
to prevent lost and spurious wakeups.
Test: atest VtsHalTvTunerTargetTest
Bug: 183057734
Change-Id: I9fb4e87e8ba887f0ce891ccb9981bfa49a3ceada
Change I154eb05bc419f827008161f85a6304a8599dc399 was incomplete and
caused some filter events to not be produced anymore. This change fixes
that issue and moves to a cleaner (and clearer!) way of creating filter events.
Note: Change I154eb05bc419f827008161f85a6304a8599dc399 did not break
VTS which is problematic.
Test: atest VtsHalTvTunerTargetTest
Bug: 183057734
Change-Id: Id018c33c16c07a9dd9de725aea64207008d317b3
mFilterEventsLock was not always being held when mFilterEvents is
modified.
Test: atest VtsHalTvTunerTargetTest
Bug: 183057734
Change-Id: I5b6bdb3bb8674d6da89665182ce1694f04dc64b2
*) Allow section filter version to be optional.
*) Add separate DemuxScAvcIndex for the AVC.
*) Support for secure MediaFilter buffer configuration.
*) Remove duplicated UNDEFINED and NONE from DemuxRecordScIndexType.
Bug: 191825295
Bug: 204807405
Bug: 204178547
Test: atest VtsHalTvTunerTargetTest
Test: atest android.media.tv.tuner.cts
Change-Id: I34af9483b3496099a159ae22360415740dd792c1
All the filter events in scheduler should be cleaned before stopping.
Sending events after stopping may cause problems if frameworks has
release some references.
Bug: 205763272
Test: atest VtsHalTvTunerTargetTest
Test: atest android.media.tv.tuner.cts
Change-Id: I2d3875b348035e14314034ff90aa8c066108affe
I am adding two minor tweaks to change
I2b9d45fa7df3f2490893cc24d98c0e0baaaf0c2c which notifies the condition
variable when trying to join the thread:
1. the mutex lock does not need to be held to notify the condition
variable.
2. adding isRunning check to existing if condition in
threadLoopOnce to condense the code.
Bug: 183057734
Test: atest android.media.tv.tuner.cts
Change-Id: Ia35e645bddd5005218e8e017a22b87b349997658
Adds a event buffering / scheduling mechanism that is configured using
the delay hint.
Bug: 183057734
Test: atest VtsHalTvTunerTargetTest
Change-Id: I154eb05bc419f827008161f85a6304a8599dc399
Because ISDB-T has up to three layers
(1) It is necessary to be able to obtain the hierarchical structure and
information of each hierarchy by getFrontendStatus. Various transmission
parameters, partial reception flags, error states at each level, etc.
(2) It is necessary to be able to set the transmission parameters of
each layer at the time of request. Various transmission parameters and
partial reception flags.
Bug: 171537116
Test: atest VtsHalTvTunerTargetTest
Test: atest android.media.tv.tuner.cts
Change-Id: I9a4b2296b83d97dcea5806f464ccf50885829f76
TunerHAL expects Hz
Fix stopRecordThread race
Push segment000000.ts to device
getFrontendIdByType() should return INVALID_ID when no FE found
Bug: 201556155
Test: VtsHalTvTunerV1_{0,1}TargetTest on BCM device
Change-Id: Idab6817e47f3e10f07a36a8b2fd805336b9f0e5d
Signed-off-by: Pierre Couillaud <pierre@broadcom.com>
If a new tuning request comes before stop old tuning, there is race
condition that the Frontend loop thread may crash while terminate().
Bug: 202335601
Fix: 202335601
Test: atest android.media.tv.tuner.cts
Change-Id: Ic168b585f0a8fe36bd8eeceee3e0b4c83d5388aa
