Device specific problems and the future

Device specific problems (DSP!) are the most nagging for audio developers on android. I would like to understand what Oboe is doing to address this problem and start a discussion.

It is important for Oboe team to understand how we, app developers, come to know about DSP (not Digital Signal Processing, of course). We have limited set of devices with us. Cloud infrastructure like Firebase Test Lab is not much help to us as they don't support audio (most devices simply muted, only screen capture videos and no sound, etc.). So we end up learning about DSPs from the worst source possible, our users. Most users just uninstall the app when they encounter audio problems. Some users are nice enough to give us one star review and leave. Of course, responding to those reviews never helped to get any further details. I hope you can understand the remote chance for ourselves to discover DSPs.

So it is not a surprise that we considered to immediately migrate our apps to Oboe when we found out about [Quirks Manager](https://github.com/google/oboe/blob/cb01be56e08c1e6ac24c3bf202dc5add75895051/src/common/QuirksManager.cpp). QuirksManager keeps growing and new issues keep showing up. This is good and bad. Good thing is that now we have a single source to workaround these problems. But not all DSPs can be addressed like this.

Basic questions: (1) Why are there DSPs? (2) How to identify existing DSPs? (3) How to prevent DSPs from occurring?

Pretty sure, Oboe team has a good idea about this and working hard on it. In my limited understanding one of the issues may be: Device manufacturers don't or don't have to adhere to [Android Compatibility Definition](https://source.android.com/compatibility/android-cdd#5_multimedia_compatibility)(CDD) fully (e.g. #911).

I believe Android Audio and/or Oboe team can do the following (It would be great to know if they are already working on these things):

1. Create automated *audio* test suite for the device and chipset manufacturers to easily validate and adhere to CDD. This way, at least the future devices will have more uniform behavior for audio.
1. If there is any unavoidable deviation from CDD, manufacturers should be given a standard way to provide info about this deviation. This could help oboe to provide workarounds more easily.
1. Proactively and continuously collect popular devices (and chipsets) and check quirks in the audio. OboeTester helps a lot but it is still manual work. There shall be and automated test suite for common scenarios to make this scalable and continuous.
1. If these test suites are made available to us app developers, we could contribute and even share test results from the devices available to us. This way of crowd sourcing can improve the coverage to even more devices.
1. Communicate continuously with manufacturers regarding quirks identified this way. I understand Oboe team is already doing this. But I think it is only case by case. Test suite can help with standardizing, simplifying, and even avoiding this communication.
1. Work with Firebase Test Lab, for example, to provide facilities to test audio apps. This will really help us to get access to more devices. We made a few requests to Firebase on this but not heard from them.
1. Work with android test team to provide features for testing audio. We have Espresso and UiAutomator, but they are just for checking UI behavior on devices, but we also need a way to check audio behavior of our apps on devices.