You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I.e. using AUDIO_OUTPUT_FLAG_DIRECT basically any sample rate and format is possible for pretty much any output.
Now (with the above commit) we have a mixport with name="direct_pcm" for this flag which is via <routes> connected to pretty much all outputs. So far so good.
The issue is likely introduced by this commit: de349af
Prior to the XML config files the
audio_policy.conf
on e.g. lilac included for example this:I.e. using
AUDIO_OUTPUT_FLAG_DIRECT
basically any sample rate and format is possible for pretty much any output.Now (with the above commit) we have a mixport with
name="direct_pcm"
for this flag which is via<routes>
connected to pretty much all outputs. So far so good.However now e.g. for the "Wired headset" output we only have a single profile: 48kHz@16Bit de349af#diff-ca13afe69a6d9ad751f1375d1dd1a847c892ea76ca115b8a1370dcfc83b671a9R177-R181
This means when selecting a matching profile the only available one for this source-sink-combination will be chosen: 48kHz@16Bit
I assume by leaving the
<devicePort>
empty ANY profile was acceptable for this sink. This is now no longer the case.This means newer devices using that new XML configuration will have degraded features.
I'd try to remove those profiles from the sinks or is there a reason for them?
Edit: Not so sure anymore. Issue seems to be related to the accessibility config "Mono-Audio" which effectively redirects "DIRECT" output to "DEEPBUFFER" output, see e.g. https://github.com/LineageOS/android_vendor_qcom_opensource_audio/blob/343077c4a5393459bc6b4a5fbccdeb0b33b6e5d4/policy_hal/AudioPolicyManager.cpp#L1727-L1731
Can anyone knowledgeable comment on whether my assumption from above is correct or not?
The text was updated successfully, but these errors were encountered: