audio: enable tinyHAL and start writing mixer paths
diff --git a/BoardConfigCommon.mk b/BoardConfigCommon.mk
index 3c06926..b7b8656 100644
--- a/BoardConfigCommon.mk
+++ b/BoardConfigCommon.mk
@@ -56,6 +56,9 @@
# BT
BOARD_HAVE_BLUETOOTH := true
+# TinyHAL
+BOARD_USES_TINYHAL_AUDIO := true
+
BOARD_SEPOLICY_DIRS += \
device/generic/sdm845/sepolicy \
system/bt/vendor_libs/linux/sepolicy
diff --git a/device-common.mk b/device-common.mk
index 94f5cda..d542303 100644
--- a/device-common.mk
+++ b/device-common.mk
@@ -112,15 +112,15 @@
# Build tinyalsa cli tools for debugging
PRODUCT_PACKAGES += \
- tinyplay \
- tinycap \
- tinymix \
- tinypcminfo
+ tinyplay2 \
+ tinycap2 \
+ tinymix2 \
+ tinypcminfo2
# audio policy configuration
USE_XML_AUDIO_POLICY_CONF := 1
PRODUCT_COPY_FILES += \
- $(LOCAL_PATH)/etc/mixer_paths.xml:$(TARGET_COPY_OUT_VENDOR)/etc/mixer_paths.xml \
+ $(LOCAL_PATH)/etc/audio.sdm845.xml:$(TARGET_COPY_OUT_VENDOR)/etc/audio.sdm845.xml \
$(LOCAL_PATH)/etc/audio_policy_configuration.xml:$(TARGET_COPY_OUT_VENDOR)/etc/audio_policy_configuration.xml \
$(LOCAL_PATH)/etc/audio_policy_configuration_bluetooth_legacy_hal.xml:$(TARGET_COPY_OUT_VENDOR)/etc/audio_policy_configuration_bluetooth_legacy_hal.xml \
frameworks/av/services/audiopolicy/config/a2dp_audio_policy_configuration.xml:$(TARGET_COPY_OUT_VENDOR)/etc/a2dp_audio_policy_configuration.xml \
diff --git a/etc/audio.sdm845.xml b/etc/audio.sdm845.xml
new file mode 100644
index 0000000..4f76781
--- /dev/null
+++ b/etc/audio.sdm845.xml
@@ -0,0 +1,355 @@
+<!-- This file is provided as a reference for writing config files
+It does NOT represent any particular device and will NOT work on
+real hardware. You must create a file with the correct settings for
+your hardware, and the comments here will explain the layout of this
+file and expected content.
+On the target device this file must be located in /system/etc and named
+audio.<device>.xml, where <device> is the string returned by the system
+property ro.product.device
+-->
+
+<audiohal>
+
+ <!-- mixer element _must_ appear before any of the other definitions.
+ The ALSA card can be identified either by card number or by name.
+ Connect to ALSA card 0:
+ <mixer card="0">
+ Connect to ALSA card called "FooSound"
+ <mixer name="FooSound">
+ When the card is given by name, TinyHAL searches all /proc/asound/card*/id
+ files for a matching name.
+ -->
+ <mixer card="0"> <!-- <mixer name="sdm845" > -->
+
+ <!-- A pre_init element lists control settings that will cause new ALSA
+ controls to be added. Typically this is used to load firmware into a
+ DSP, causing new ALSA controls to be added for controls exported by the
+ firmware. After processing a pre_init element the ALSA controls are
+ reloaded to pick up any new controls. Other elements in the
+ configuration can then use those controls.
+ Multiple pre_init elements can be used, so that a pre_init can depend
+ on controls populated by a previous pre_init.
+ All pre_init elements must appear before the init element.
+ -->
+
+ <pre_init>
+ <!-- A list of ctl elements - see description of init element -->
+ <!-- <ctl name="DSP1 Preload Switch" val="1" /> -->
+ </pre_init>
+
+ <!-- An init element lists control settings required to initialize the
+ hardware and driver. These settings are applied only once when the
+ library is first loaded during boot.
+ -->
+
+ <init>
+
+ <!-- A sequence of ctl elements. Each entry sets a mixer
+ control to a given value. The entries are applied in the
+ order they are listed here.
+ Each entry _must_ have these attributes
+ name - name of the ALSA mixer control
+ val - value to set it to
+ It can also have an index attribute giving the numeric index
+ of the control value to set. This is used where a control
+ has multiple value slots (for example a volume control
+ with two values, one for left channel and one for right), If
+ an index attribute is not given the content of the val attribute
+ will be applied to all value slots of the control.
+ The numbers in val and index attributes can be given in either
+ decimal, or hex (hex is prefixed with 0x). For a control with
+ enumerated values the val attribute must be a string
+ BYTE ARRAYS: for controls that are a byte array val must be
+ a string of comma-separated byte values. This can be shorter
+ than the total size of the control, combined with the
+ optional index attribute this allows any subset of the byte
+ array to be changed. Alternatively, a file attribute can be given
+ instead of the val attribute, and the raw byte content of the file
+ will be copied into the control. Note that the bytes in the file
+ must already be correctly formatted for writing into the ALSA
+ control. The file is read once when TinyHAL starts and this
+ cached content is used every time this <ctl> element is invoked.
+ -->
+
+ <ctl name="QUAT_MI2S_RX Audio Mixer MultiMedia1" val="1" />
+ <ctl name="SLIMBUS_0_RX Audio Mixer MultiMedia2" val="1" />
+ <ctl name="MultiMedia3 Mixer SLIMBUS_0_TX" val="1" />
+ <ctl name="AIF1_CAP Mixer SLIM TX7" val="1" />
+ <ctl name="CDC_IF TX7 MUX" val="DEC7" />
+ <ctl name="SLIM RX0 MUX" val="AIF1_PB" />
+ <ctl name="SLIM RX1 MUX" val="AIF1_PB" />
+ <ctl name="SLIM RX2 MUX" val="AIF1_PB" />
+ <ctl name="SLIM RX3 MUX" val="AIF1_PB" />
+ <ctl name="SLIM RX4 MUX" val="ZERO" />
+ <ctl name="SLIM RX5 MUX" val="ZERO" />
+ <ctl name="SLIM RX6 MUX" val="ZERO" />
+ <ctl name="SLIM RX7 MUX" val="ZERO" />
+ <ctl name="RX INT7_1 MIX1 INP0" val="RX0" />
+ <ctl name="RX INT8_1 MIX1 INP0" val="RX1" />
+ <ctl name="RX INT1_2 MUX" val="RX0" />
+ <ctl name="RX INT2_2 MUX" val="RX1" />
+
+
+ </init>
+ </mixer>
+
+<!-- Next you must list all the devices supported by the hardware. The
+name attribute of the <device> element identifies the device. These names are
+recognized:
+ "global" dummy global device - see explanation below
+ "speaker" AUDIO_DEVICE_OUT_SPEAKER
+ "earpiece" AUDIO_DEVICE_OUT_EARPIECE
+ "headset" AUDIO_DEVICE_OUT_WIRED_HEADSET
+ "headset_in" AUDIO_DEVICE_IN_WIRED_HEADSET
+ "headphone" AUDIO_DEVICE_OUT_WIRED_HEADPHONE
+ "sco" AUDIO_DEVICE_OUT_ALL_SCO
+ "sco_in" AUDIO_DEVICE_IN_ALL_SCO
+ "a2dp" AUDIO_DEVICE_OUT_ALL_A2DP
+ "usb" AUDIO_DEVICE_OUT_ALL_USB
+ "mic" AUDIO_DEVICE_IN_BUILTIN_MIC
+ "back mic" AUDIO_DEVICE_IN_BACK_MIC
+ "voice" AUDIO_DEVICE_IN_VOICE_CALL
+ "aux" AUDIO_DEVICE_IN_AUX_DIGITAL
+Within the <device> element you can declare a number of "paths", each path
+defines a group of control settings to be applied. Each path is identified by
+a name. The "on" and "off" paths are special and list a global enable and
+disable setting for the device. Use of devices is reference-counted, when
+routing of a stream is changed to use a device that is currently disabled its
+"on" path will be applied. When no streams are using a device its "off"
+path will be applied.
+Other paths are user-defined and you can give them any name you choose.
+They are used to apply custom paths when required by a stream and will
+be used only when a stream is connected to or disconnected from a
+device if the <stream> element has an <enable> or <disable> element requesting
+that path.
+It is not mandatory to provide paths. You only need to define paths
+if there are specific control settings that must be applied. So for example
+if no controls need be applied to enable or disable a device then you
+do not need to define the "on" and "off" paths.
+The <ctl> elements within each path have the same format and behaviour
+as described under <mixer><init>.
+The "global" device is a special device the represents the audio system as a
+whole and is used to invoke mixer settings that are independent of any real
+device and which apply globally to the audio system. A stream is automatically
+connected to "global" when it is opened and disconnected when it is closed.
+The behaviour is identical to the way paths are invoked in any other <device>
+entry so the effect is
+ - the "on" path will be applied when a stream is opened and there are
+ no other streams already open. As an example this could be used to
+ bring the audio hardware out of a standby state
+ - the "off" path will be applied when the last open stream is closed.
+ As an example this could be used to put the audio hardware into a
+ standby state
+ - the custom paths will be applied when the stream that requests them
+ is opened or closed.
+-->
+
+ <device name="speaker">
+ <path name="on">
+ <!-- List of ctl element for control values to apply
+ when this device is enabled -->
+ <!-- <ctl name="Amp DSP Switch" val="1"/> -->
+ </path>
+
+ <path name="off">
+ <!-- List of ctl element for control values to apply
+ when this device is disabled -->
+ <!-- <ctl name="Amp DSP Switch" val="0"/> -->
+ </path>
+
+ <!-- Following paths are user-defined and are applied when a
+ <stream> elements' routing is changed to add or remove this
+ device. If the path name matches the name given in the <stream>
+ element it will be applied. A stream could be routed to multiple
+ inputs or outputs - the paths for connecting and disconnecting
+ a stream to a device must therefore have the same name in each
+ <device>.
+ It is not mandatory to declare custom paths - depending on your
+ hardware there may not be any specific action required to route
+ a stream to a particular device. Also you do not have to define
+ the path in every device, only the devices where some action must
+ be taken to connect or disconnect a stream.
+ For this example four custom paths are defined:
+ pcm_out_en = control setting to connect PCM output to this device
+ pcm_out_dis = control setting to disconnect PCM output from this device
+ -->
+
+ <path name="pcm_out_en">
+ <ctl name="I2S RX0 MUX" val="AIF1_PB" />
+ <ctl name="MI2S_RX Channels" val="One" />
+ <ctl name="CDC_IF RX0 MUX" val="I2S RX0" />
+ <ctl name="RX INT8_1 MIX1 INP0" val="RX0" />
+ <ctl name="COMP8 Switch" val="1" />
+ <ctl name="SpkrRight COMP Switch" val="1" />
+ <ctl name="SpkrRight BOOST Switch" val="1" />
+ <ctl name="SpkrRight VISENSE Switch" val="1" />
+ <ctl name="SpkrRight SWR DAC_Port Switch" val="1" />
+ </path>
+ <path name="pcm_out_dis">
+ </path>
+ </device>
+
+ <device name="headphone">
+ <!-- <path name="on">
+ <ctl name="SLIM RX2 MUX" val="AIF1_PB"/>
+ <ctl name="SLIM RX3 MUX" val="AIF1_PB"/>
+ <ctl name="RX INT1 DEM MUX" val="CLSH_DSM_OUT"/>
+ <ctl name="RX INT2 DEM MUX" val="CLSH_DSM_OUT"/>
+ <ctl name="RX INT1_1 MIX1 INP0" val="RX2"/>
+ <ctl name="RX INT2_1 MIX1 INP0" val="RX3"/>
+ <ctl name="RX INT1_1 INTERP" val="RX INT1_1 MI"/>
+ <ctl name="RX INT2_1 INTERP" val="RX INT2_1 MI"/>
+ <ctl name="RX0 Digital Volume" val="0"/>
+ <ctl name="RX1 Digital Volume" val="80"/>
+ <ctl name="RX2 Digital Volume" val="80"/>
+ </path>
+
+ <path name="off">
+ <ctl name="SLIM RX2 MUX" val="ZERO"/>
+ <ctl name="SLIM RX3 MUX" val="ZERO"/>
+ <ctl name="RX INT1 DEM MUX" val="ZERO"/>
+ <ctl name="RX INT2 DEM MUX" val="ZERO"/>
+ <ctl name="RX INT1_1 MIX1 INP0" val="ZERO"/>
+ <ctl name="RX INT2_1 MIX1 INP0" val="ZERO"/>
+ <ctl name="RX INT1_1 INTERP" val="ZERO"/>
+ <ctl name="RX INT2_1 INTERP" val="ZERO"/>
+ <ctl name="RX1 Digital Volume" val="0"/>
+ <ctl name="RX2 Digital Volume" val="0"/>
+ </path> -->
+
+
+ <path name="pcm_out_en">
+ <ctl name="SLIM RX2 MUX" val="AIF4_PB" />
+ <ctl name="SLIM RX3 MUX" val="AIF4_PB" />
+ <ctl name="RX INT1_2 MUX" val="RX2" />
+ <ctl name="RX INT2_2 MUX" val="RX3" />
+ </path>
+
+ <path name="pcm_out_dis">
+ <ctl name="SLIM RX2 MUX" val="ZERO" />
+ <ctl name="SLIM RX3 MUX" val="ZERO" />
+ <ctl name="RX INT1_2 MUX" val="ZERO" />
+ <ctl name="RX INT2_2 MUX" val="ZERO" />
+ </path>
+ </device>
+
+<!-- Following the device definitions there must be a <stream> entry
+for every output and input stream supported by the hardware. It is also
+possible to define a 'global' stream that is not associated with any particular
+audio input or output but instead can be used to handle actions that are
+global to the audio hardware.
+There are two types of stream that can be declared here:
+- anonymous streams, these will be used to supply playback and record
+ streams for AudioFlinger
+- named streams, which are mainly used to declare custom streams to handle
+ special routing use-cases that are external to the normal Android audio
+ path - typically where the audio is routed entirely in hardware without
+ being passed through Android, for example the baseband audio link or
+ FM radio.
+ The global stream is a special case of a named stream and must have the
+ name "global"
+For standard anonymous streams there are two that would normally be on
+any device: PCM input and PCM output. It is also possible to declare a stream
+as "compress" - this is intended for cases where a playback stream is
+decompressed in hardware, or a record stream provides raw compressed data that
+must be decompressed in software.
+Named streams can be declared as type "hw", to represent a hardware-hardware
+link.
+The "global" named stream can be used to handle events that are not specific
+to any particular stream. Typically this is used to implement usecase handlers
+(see below) to handle set_parameter messages sent to the HAL's global
+(struct audio_device*)->hw_device.set_parameters function (for example, the
+"orientation" parameter that is sent by Android.)
+Mandatory attributes for PCM and compressed streams:
+ type must be "pcm" or "compress"
+ dir direction of stream, either "in" (recording) or "out" (playback)
+Mandatory for named streams:
+ type must be "pcm", "compress" or "hw"
+ dir direction of stream, either "in" (recording) or "out" (playback)
+ name a custom name for a named stream. The name you choose here must
+ match the name your HAL will use to request this stream
+Mandatory for hw streams:
+ type must be "hw"
+ dir direction of stream, either "in" (recording) or "out" (playback)
+ name a custom name for the stream (hw streams must be named streams)
+Mandatory for the global stream:
+ type must be "hw"
+ name must be "global"
+Optional attributes:
+ card ALSA card number. If not given this defaults to 0
+ device ALSA device number. If not given this defaults to 0
+ instances limits the maximum number of instances of this stream, if not
+ specified the number of instances is unlimited
+ name a custom name for a named stream. The name you choose here must
+ match the name your HAL will use to request this stream
+Anonymous PCM streams should not normally have an instance limit.
+TinyHAL defines a specific named stream:
+"voice recognition" - a PCM or compressed stream for voice recognition input.
+ If a stream with this name is not defined TinyHAL will
+ use the normal PCM input stream for voice recognition audio.
+-->
+
+ <stream type="pcm" dir="out" card="0" device="0">
+ <!-- The <enable> and <disable> tags give the name of a path
+ to apply for each connected device when the stream is either connected
+ to (enable) or disconnected from (disable) that device.
+ The way this works is that when stream routing changes, the HAL will
+ look through the paths of each device this stream is connected to,
+ - for each device the stream is being disconnected from, if it
+ contains a path matching the path name in <disable>, that path
+ will be applied.
+ - for each device the stream is being connected to, if it
+ contains a path matching the path name in <enable>, that path
+ will be applied.
+ -->
+ <enable path="pcm_out_en"/>
+ <disable path="pcm_out_dis"/>
+
+ <!-- The optional usecase block allows you to define custom use-cases that
+ are triggered by set_parameter() calls to the HAL. The set_parameter()
+ is a string of the form <setting>=<value>. The HAL will search for a
+ usecase block whose name attribute matches <setting> and within that
+ a case block whose name attribute matches <value>. If a matching case
+ block is found the enclosed <ctl> blocks will be applied.
+ The example below defines a use case for switching a codec algorithm
+ between wideband and narrowband response. The two cases will be
+ triggered by a set_parameter() of "bandwidth=narrow" or "bandwidth=wide".
+ -->
+ <!-- <usecase name="bandwidth">
+ <case name="narrow">
+ <ctl name="Codec Wideband" val="0" />
+ </case>
+ <case name="wide">
+ <ctl name="Codec Wideband" val="1" />
+ </case>
+ </usecase> -->
+
+ <!-- Constant values. These allow setting named values that can
+ be read by the audio HAL at runtime. Values are 32-bit unsigned.
+ This is useful for setting HAL-specific or hardware-specific
+ information.
+ The names have no meaning to the config manager, and are
+ entirely defined by the audio HAL.
+ If you want to set constants that are global, rather than part
+ of a stream, define a hw stream called "global".
+ to hold the values.
+ -->
+ <!-- <set name="foo" val="42"/> -->
+
+ </stream>
+
+ <stream type="pcm" dir="out" card="0" device="1">
+ </stream>
+
+ <!-- Example named stream, in this case for an FM radio path . This will not
+ be available for standard AudioFlinger playback and record paths. It must
+ be explicitly requested by the audio HAL when FM radio is enabled
+ -->
+ <!-- control paths to be enabled when this stream is enabled or disabled -->
+ <!-- <stream name="FM radio" type="pcm" dir="in" card="0" device="0">
+
+ <enable path="fm_radio_en"/>
+ <disable path="fm_radio_dis"/>
+ </stream> -->
+
+</audiohal>
diff --git a/etc/mixer_paths.xml b/etc/mixer_paths.xml
index db4db9d..1f32bcb 100644
--- a/etc/mixer_paths.xml
+++ b/etc/mixer_paths.xml
@@ -98,4 +98,9 @@
tinymix "RX1 Digital Volume" 84
tinymix "RX2 Digital Volume" 84
+tinymix2 set "SLIM RX2 MUX" "AIF4_PB"
+tinymix2 set "SLIM RX3 MUX" "AIF4_PB"
+tinymix2 set "RX INT1_2 MUX" "RX2"
+tinymix2 set "RX INT2_2 MUX" "RX3"
+
-->
\ No newline at end of file