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:

      direct_pcm {
        sampling_rates 8000|11025|12000|16000|22050|24000|32000|44100|48000|64000|88200|96000|176400|192000|352800|384000
        channel_masks AUDIO_CHANNEL_OUT_MONO|AUDIO_CHANNEL_OUT_STEREO|AUDIO_CHANNEL_OUT_2POINT1|AUDIO_CHANNEL_OUT_QUAD|AUDIO_CHANNEL_OUT_PENTA|AUDIO_CHANNEL_OUT_5POINT1|AUDIO_CHANNEL_OUT_6POINT1|AUDIO_CHANNEL_OUT_7POINT1
        formats AUDIO_FORMAT_PCM_16_BIT|AUDIO_FORMAT_PCM_24_BIT_PACKED|AUDIO_FORMAT_PCM_8_24_BIT|AUDIO_FORMAT_PCM_32_BIT
        devices AUDIO_DEVICE_OUT_SPEAKER|AUDIO_DEVICE_OUT_EARPIECE|AUDIO_DEVICE_OUT_WIRED_HEADSET|AUDIO_DEVICE_OUT_WIRED_HEADPHONE|AUDIO_DEVICE_OUT_LINE|AUDIO_DEVICE_OUT_ALL_SCO|AUDIO_DEVICE_OUT_PROXY|AUDIO_DEVICE_OUT_USB_DEVICE|AUDIO_DEVICE_OUT_USB_HEADSET|AUDIO_DEVICE_OUT_BLUETOOTH_A2DP|AUDIO_DEVICE_OUT_BLUETOOTH_A2DP_HEADPHONES|AUDIO_DEVICE_OUT_BLUETOOTH_A2DP_SPEAKER
        flags AUDIO_OUTPUT_FLAG_DIRECT
      }

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?

I assume by leaving the <devicePort> empty ANY profile was acceptable for this sink.

I have attached the dmes, event, logcat and modem logs of my device
between the time 13:04:39.712 to 13:04:40.737 there were calls which triggered a restart of the device (XZ1 Compact).

dmesg.log
event.log
logcat.log
modem.log

The XZ1 (poplar) video camera is capable of 2160p@30fps, 1080p@30/60fps, 720p@960fps (slo-mo). Currently, if we try to use it at 1080p@60, as was enabled briefly by commit d4ea034, the camera fails to start recording and an error is logged saying the camera is only capable of 15/20/24/30fps. The 2160p resolution is also not available.