The legacy HAL wrapper prepareForWrite and prepareForRead used
to return INVALID_ARGUMENTS if the computed buffer size just
under SIZE_MAX.
This meant that the limitation depended on the architecture (32 vs 64
bit size_t). This caused VTS test failure on 64 bits.
Instead of dynamically calculating an arbitrary max size,
choose a fixed one. This max buffer size has been chosen at 1GiB.
It should be enough for the foreseeable future and not too close
from the 4GiB max on 32 bit.
Test: vts-tradefed run commandAndExit vts --module VtsHalAudioV2_0Target
Bug: 67030516
Change-Id: I4cc3efda9bb66e6dae8b4e6785f52d9e51440aee
Signed-off-by: Kevin Rocard <krocard@google.com>
get_presentation_position can return ENODATA if the stream
has stopped but the write is still querying the position.
Bug: 38376424
Change-Id: I9d516a19fb347843a8ec8e8e9a0f5eab0b0798e6
Test: no log messages from StreamHAL about get_presentation_position
Hals are supposed to received normalized volumes, between 0 and 1.
Previously volumes outside [0,1] were clamp to this range.
This clamping has the capability to hide bugs thus return an error if
such volume is received.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: Ia4880bdff6111cbcdae6a4ebee921eddae141ee4
Signed-off-by: Kevin Rocard <krocard@google.com>
Return an error if framesCount or frameSize are null to avoid a division
by zero when calculating the buffer size.
The message queues are allocated with a buffer size but if two big they will
assert not return an error.
Thus take some margin on the buffer size check.
Note that both function should be refactored as 99% identical.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: I0576e9016ef2e567c8d4e171c6237883d9865db9
Signed-off-by: Kevin Rocard <krocard@google.com>
Those functions had lots of copy paste on errors and
the following patch will even add more error detections.
Refactor the hidl_cb call to avoid all duplication.
Note that both function should be refactored as 99% identical.
Test: vts-tradefed run vts --module VtsHalAudioV2_0Target
Test: call/play music/record/video...
Bug: 36311550
Change-Id: I40d6926b4f9f5e3aba51e878f55fb013f4ca09c1
Signed-off-by: Kevin Rocard <krocard@google.com>
In order to avoid style inconsistency as well as non functional
modification in following patches,
fix the style of all files modified for the fix of the VTS tests.
Patch generated with:
$ clang-format -i --style file -- <file list>
Bug: 36311550
Test: compile
Change-Id: I53dbcdabf959a6100e34a2ee4d0f951d525049cb
prepare for write was refactor by Ib4170eb6a9f88f9352d0912083b43d600771bb8e
to use temporary variable in a rai pattern.
Nevertheless the member variable was still used too early in
prepareForRead resulting in a crash for capture.
Test: assistant, camcorder
Bug: 37492059
Change-Id: I08140834959c440798cd40700dd089adca2f3e40
Signed-off-by: Kevin Rocard <krocard@google.com>
If prepareToWrite or prepareToRead fails after EventFlag is created, it
is not destroyed. This lead to strange random crashes (double free it seems).
Use the RAII pattern to manage the EventFlag life cycle.
Test: Run test on target
Bug: 36311550
Change-Id: I53a04a62b7d12fdcc94afd8ced3e547aa6edff50
Signed-off-by: Kevin Rocard <krocard@google.com>
The audio buffer size is not provided by the client, it is computed from
the sample size and the number of sample.
No check was done as if the multiplication of these two numbers would
produce an overflow. This leaded to erroneous memory access crashing the
media server.
Test: Run on target
Bug: 36311550
Change-Id: I3436800ab6ac1b5e6a6aa4d03d6b96910eb54652
Signed-off-by: Kevin Rocard <krocard@google.com>
If the requested buffer was too big, memory allocation would fail,
resulting if a audio hal crash (uncatch exception thrown by new).
Properly hadle the failure by retuning INVALID_PARAMETERS in such case.
Bug: 36311550
Test: Run test on target
Change-Id: Ib4170eb6a9f88f9352d0912083b43d600771bb8e
Signed-off-by: Kevin Rocard <krocard@google.com>
Stream objects used to hold a pointer to underlying HAL device
object which they didn't own. Since destruction of server side
objects is asynchronous, it was possible that a Device object
gets destroyed before Stream objects, making all the HAL device
object pointer to become stale.
Fixed by adding a strong reference to Device objects into Stream
objects.
Bug: 36702804
Change-Id: I3da3611afbb91d6fd6410ac5b8af2a2eebfa6dac
Test: ran Loopback app and HAL VTS tests
(cherry picked from commit 96d3573cda)
This fixes a power regression caused by periodic wakeups of
the driver threads even when the device is idle.
The timeout is really not needed, it used to be there to ensure that
the thread exits its loop, but then an explicit wake-up call before
closing the thread had been added for this purpose.
Bug: 34682579
Test: Follow repro steps from the bug, compare power consumption
to the legacy version of the audio HAL.
Change-Id: I0bfc2079a449894c5d0bd6ef19b53ca425795a9e
HALs are prohibited from using framework binder, and there is
no equivalent scheduling policy service in hwbinder. Thus, in order
to match priorities of FastCapture / Mixer threads with their
counterparts in the HAL, it is needed to request the priority boost
from audioflinger on behalf of the HAL.
Bug: 34131400
Change-Id: I7c8db9d520b4cf272d2896ad875752b109b57ab7
Test: check priority match between audioflinger's and hal's threads
When outputting audio, the framework issues several HAL calls
from the same thread that writes into data FMQ. These calls
also need to be served on the same thread that writes audio data
to HAL. The same thing happens when audio input is commenced.
Add a command FMQ for passing different commands to the HAL thread.
This way, depending on the calling thread, the same call may go
either via hwbinder or via the command queue.
This dramatically reduces jitter in RTT measurements (although
doesn't improve the latency).
Bug: 30222631
Test: scripted RTT app
Change-Id: I04c826e2479d8210fd9c99756241156cda3143b6
There were two problems:
1. Joining of reader / writer / process threads (the threads that
interact with HAL) was taking up to 1 second because the thread
was usually waiting for an event flag to be toggled, or a 1s
timeout.
2. Calling IStream.close or IEffect.close shouldn't tax the caller.
Changed the code so a call to close only signals the thread that
it's time to exit, and then the thread is only joined in the
effect or stream destructor.
Bug: 34800063
Bug: 34499806
Test: see repro steps in the bugs
Change-Id: Ife20524a1eba4ec9a78152e89862526e8cd5c960
The combo call to stream_out->write + get_presentation_position
wasn't delivering the results of these calls entirely
correctly. Since the 'WriteResult' struct was lacking the field
for returning the status of the call to
'get_presentation_position', the client could erroneously update
the presentation position to bogus values if the call to the
legacy HAL had failed.
Updated IStreamOut.WriteStatus to include the missing field,
and updated the code to fill it out.
Also fixed logspam resulting from calling a stubbed
stream_in->get_capture_position.
Bug: 30222631
Test: Loopback RTT, media CTS
Change-Id: I38ac3b01beb095e176b54608e11e71ae5d5eafb6
Result: no hwbinder calls due read / write session.
Added IStream.close method for explicitly freeing up of resources
consumed by the stream before automatic server objects reaping
gets to it.
Test: make, perform Loopback RTT, check traces
Bug: 30222631
Change-Id: I678559f6ef30026685df787cd2ba7c2ee449ed27
Changes made to the .hal definition:
- introduce Effect ID returned by the IEffectsFactory that
needs to be passed to IStream.{add|remove}Effect; otherwise
it's impossible to retrieve the underlying HAL effect handle;
- change "bus address" in DeviceAddress to "string" type;
- fix signature of some methods w.r.t. returning Result;
- remove unused "struct AudioPatch".
Bug: 30222631
Test: make
Change-Id: Icb51729ef57bb2a5b0b78609735e7481bc04f95c
