Audio policy: fix input preemption logic
Fix the input preemption logic in AudioPolicyManager::getInputForDevice when the maximum number of opened input stream is reached: - avoid preemption loops between two AudioRecord clients - avoid cases were no preemption occurs but an attempt is made to open a new input anyway. The new logic is: 1) reuse an input if the new client has the same session as an existing client on this input 2) try to close/preempt an input if possible and then reuse an input 3) the candidate inputs for preemption are inputs with strictly lower priority use cases than the new client, or same priority that were not opened thanks to preemption or have been active since, ordered by use case priority and favoring idle inputs as second criteria 4) if no candidates for preemption are found, reuse preferably inputs with the same use case as the new client and favoring active inputs as second criteria. Bug: 338446410 Test: atest audiopolicy_tests:AudioPolicyManagerInputPreemptionTest Flag: com.android.media.audioserver.fix_input_sharing_logic Change-Id: I82a953edcf1b3ea76a44ae0d02c943daaacfea64
Loading
Please register or sign in to comment