Hi,
Glad that helped. I am going to take in the data on this for a little while but my current suspicion is that the majority of cases will be fixed by disablePreferredBufferSize and that maybe a minority will also benefit from disablePreferredSampleRate, and so far I haven’t heard of any that needed the channel override to be functional. On the assumption that it will help the most users while making the least changes, my recommendation would be to start by using disablePreferredBufferSize, pay attention for reports of issues with BT devices that might confirm that the other setting is also needed, do your own tests of performance (the interesting performance question is CPU usage when there is absolutely no speech or anything perceived as speech) and let me know about them in the general BT thread, and always start your troubleshooting process by upgrading to all current versions. It isn’t humane UX to give users multiple choices for managing their own device compatibility – I would either have one “Bluetooth compatibility mode” switch that turns on as many of the settings as your testing has demonstrated it’s reasonable to ship with, or simply set them on with no switch and carefully test whether there is any negative impact on your use case when Bluetooth isn’t being used.