audiohal: Make sure audio data transfer related commands go via FMQ
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
diff --git a/audio/2.0/IStreamIn.hal b/audio/2.0/IStreamIn.hal
index 9a96f71..e34c95f 100644
--- a/audio/2.0/IStreamIn.hal
+++ b/audio/2.0/IStreamIn.hal
@@ -41,6 +41,26 @@
setGain(float gain) generates (Result retval);
/*
+ * Commands that can be executed on the driver reader thread.
+ */
+ enum ReadCommand : int32_t {
+ READ,
+ GET_CAPTURE_POSITION
+ };
+
+ /*
+ * Data structure passed to the driver for executing commands
+ * on the driver reader thread.
+ */
+ struct ReadParameters {
+ ReadCommand command; // discriminator
+ union Params {
+ uint64_t read; // READ command, amount of bytes to read, >= 0.
+ // No parameters for GET_CAPTURE_POSITION.
+ } params;
+ };
+
+ /*
* Data structure passed back to the client via status message queue
* of 'read' operation.
*
@@ -51,24 +71,36 @@
*/
struct ReadStatus {
Result retval;
- uint64_t read;
+ ReadCommand replyTo; // discriminator
+ union Reply {
+ uint64_t read; // READ command, amount of bytes read, >= 0.
+ struct CapturePosition { // same as generated by getCapturePosition.
+ uint64_t frames;
+ uint64_t time;
+ } capturePosition;
+ } reply;
};
/*
* Set up required transports for receiving audio buffers from the driver.
*
- * The transport consists of two message queues: one is used for passing
- * audio data from the driver to the client, another is used for reporting
- * read operation status (amount of bytes actually read or error code),
- * see ReadStatus structure definition.
+ * The transport consists of three message queues:
+ * -- command queue is used to instruct the reader thread what operation
+ * to perform;
+ * -- data queue is used for passing audio data from the driver
+ * to the client;
+ * -- status queue is used for reporting operation status
+ * (e.g. amount of bytes actually read or error code).
+ * The driver operates on a dedicated thread.
*
* @param frameSize the size of a single frame, in bytes.
* @param framesCount the number of frames in a buffer.
- * @param threadPriority priority of the thread that performs reads.
+ * @param threadPriority priority of the driver thread.
* @return retval OK if both message queues were created successfully.
* INVALID_STATE if the method was already called.
* INVALID_ARGUMENTS if there was a problem setting up
* the queues.
+ * @return commandMQ a message queue used for passing commands.
* @return dataMQ a message queue used for passing audio data in the format
* specified at the stream opening.
* @return statusMQ a message queue used for passing status from the driver
@@ -79,7 +111,9 @@
ThreadPriority threadPriority)
generates (
Result retval,
- fmq_sync<uint8_t> dataMQ, fmq_sync<ReadStatus> statusMQ);
+ fmq_sync<ReadParameters> commandMQ,
+ fmq_sync<uint8_t> dataMQ,
+ fmq_sync<ReadStatus> statusMQ);
/*
* Return the amount of input frames lost in the audio driver since the last