Since it's possible to open an output stream on the submix HAL before the input
stream is open, writes to the output stream that fill the shared pipe result in
indefinitely blocking the thread writing to the stream. This change modifies
the behavior of writes to a submix output stream such that if a write would
result in blocking the thread and an input isn't open, the pipe is flushed
of the appropriate amount of data such that the write will not block.
Bug: 11273000
Change-Id: Ic81c50e4b44b777273191a1bc8cdf52181c3d2a0
This change is primarily being made as a short term solution to allow an input
audio stream received over the network to be fed into an audio input stream (e.g
the MIC stream) when a physical audio input device isn't present.
This makes both the input and output streams owners of the pipe so that
creation order no longer matters. In addition, it works around a memory leak
caused by applications that never close input streams.
Bug: 11273000
Change-Id: I5a3fb0b6f2148c113b2f3050b72ff2a8979a3e6d
ARC, Audio Return Channel is newly introduced in HDMI CEC 1.4.
Here is a list of new command
<Initiate ARC>
<Report ARC Initiated>
<Report ARC Terminated>
<Request ARC Initiation>
<Request ARC Termination>
<Terminate ARC>
Along with it replaced <Get OSD Name> with <Give OSD Name>
which is renamed in CEC 1.4.
Change-Id: I6a03b30cf90a8f6dca54831355be05682a6df96c
MultiHal will now accept sensor HALs listed in the hals.conf file that
reside in either /system/lib/hw or /system/vendor/lib.
Bug: 14994424
Change-Id: I13f17352b97c36b97cfbcee8c9b6a0d2e1ed6dc3
This modifies the submix module to allow the internal buffer to be any NBAIO
format. This is useful when sending audio of arbitrary formats between
processes. AudioFlinger continues to enforce format restrictions as specified
by the device specific audio_policy.conf so the submix streams will have the
same restrictions as before.
Bug: 11273000
Change-Id: I2cd4ff383c5c75e491ab22bc1949c835f04e230f
This change stores the period size (fraction of the pipe buffer size)
in the submix device's configuration which is then used to calculate
the input and output stream buffer size.
In addition, accessors for the input / output stream format have been
modified to use the pipe format in the device configuration rather than
returning hard coded values.
Bug: 11273000
Change-Id: I9c14f8d549f4b4a6d7f77a9aeab4edfa5ba6bd1a
This change cleans up casting from contained to container structures.
Such that if..
struct child {
struct parent;
int child_data;
};
is changed to...
struct child {
int child_data;
struct parent;
};
functions that cast from "parent" to "child" will continue to function
correctly.
Change-Id: I88d70930d4d4df2e291239e562971b07d8b92f94
Follow up from change Ibe4300275286ef275b2097534c84f1029d761d87
which extends comments to the nfc_nci_module_t and nfc_nci_device_t
structures.
Change-Id: I060bda450912ff3fc041027faa8f03c24e310870
Inheritance of HAL object is performed by composing a child structure of a
single parent structure located at offset 0 followed by new data members
and function pointers in the child structure.
For example,
struct child {
struct parent common;
int a_data_member;
void (*a_method)(struct child *c, int v);
};
HAL code assumes this layout when accessing child structures given a pointer
to a parent structure such that users write code like the following...
void child_method(struct *parent, int v) {
struct child * c = (struct child*)parent;
// do stuff with c
}
Code above will break if a member is added before "common" in "struct child".
This change adds comments that describe the restriction on the location of
parent HAL objects within a derived HAL object. HAL objects that already
have comments that describe the required location of parent objects are not
modified.
Change-Id: Ibe4300275286ef275b2097534c84f1029d761d87
Along with the following minor changes:
* Fixed all referenced variable compiler warnings.
* Ordered headers in alphabetical order.
Change-Id: I122ef67d25b78056a60b85baf897005293a9efa0
The existing API exposed to clients for software lock/unlock forces the gralloc
implementation to complete these operations synchronously. This change adds new
entry points for lock/unlock functionality that is suited for use with Android's
explicit synchronisation concept. This provides scope for the gralloc module
to internally optimise the work it must do for lock/unlock and to hide this cost
from the client.
Change-Id: If4b1bb5490ab2b20d796214a7da8a96427cfe52d
The existing API exposed to clients for software lock/unlock forces the gralloc
implementation to complete these operations synchronously. This change adds new
entry points for lock/unlock functionality that is suited for use with Android's
explicit synchronisation concept. This provides scope for the gralloc module
to internally optimise the work it must do for lock/unlock and to hide this cost
from the client.
Change-Id: I6c41f4a532b705fc76c7777b2f04ea293506b381
