[Context]
When a LOOPBACK dynamic audio policy mix PLAYER/RECORDER
is registered, first the REMOTE_SUBMIX device that will be
used by the app to capture/play respectively is activated.
Eg a mix RECORDER (used to inject audio to apps recording),
when registered will activate an OUT_REMOTE_SUBMIX.
Then the app can open a record/playback track on this
REMOTE_SUBMIX, which will trigger the other end of the pipe
to be activated.
Following this the playback/Record Tracks that match the
mix will be routed to the IN/OUT REMOTE_SUBMIX.
[Example for an app FUU]
1) App FUU register Playback/record mix
2) APM activates out/in remote submix
3) App FUU opens track to out/in remote submix
4) APM activates in/out remote submix
5) tracks matching mix are redirected to the out/in remote submix
When an OUT_REMOTE_SUBMIX is activated, it tries to check if it matches
a mix, if it does, it saves the output in the mix (in mOutput).
This output is then used to find a matching mix output in
getOutputForAttr(). If a mix has no output is is considered inactive.
Note that IN_REMOTE_SUBMIX do not save their input in the mix, the
input is queried by APM each time in its mAvailableInputDevices.
[Issue]
The issue is that in step (2), when an OUT_REMOTE_SUBMIX is
activated (thus for a MIX_TYPE_RECORDERS), no mix is matched because the
mix is of type IN_REMOTE_SUBMIX as it will be used to route AudioTracks
in step (5).
Thus no mix output is found in getOutputForAttr and the step (3) fails.
This is a recent regression as previously the type was not checked when
looking up for a mix in step (1).
The Change-Id of the patch that caused the regression is:
I4dc7f23bef19a7d47afc2998102da07dde41fbca, its sha1 is:
679172768d
[Workaround]
For now, given the release timing, implement a minimal fix that restore
the previous behavior for the OUT_REMOTE_SUBMIX output save lookup.
Aka, make sure to query for a IN_REMOTE_SUBMIX mix in step (2).
Step (4) is fine as the mix type is the same as the REMOTE_SUBMIX type.
As IN_REMOTE_SUBMIX do not attempt to save their output in the mix, no
issue is present on this code path.
A proper fix needs to be implemented on master, preferably by having the
same device save behaviour on both mix type.
Bug: 134068143
Test: Wifi calling call screening
Test: atest AudioPlaybackCaptureTest AudioHostTest
Change-Id: I1547948ae412dbdeb2d85cc62bf18f7ac5f1efc0
Signed-off-by: Kevin Rocard <krocard@google.com>
Kevin Rocard
4e5f402253