-
Notifications
You must be signed in to change notification settings - Fork 563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Device specific problems and the future #914
Comments
@rpattabi - Thanks for this letter. It is very helpful to hear from developers about this issue. I will be sharing this with our management. I agree with your sentiment and we are trying to fix this problem.
Primarily from lack of automated test suites and/or not enough manual testing. We do have lots of automated API tests through CTS. But testing audio hardware and device drivers can involve listening to audio, recording sound, plugging in headphones and other tasks that cannot be easily automated. We are working on it. But it is just harder and often requires specialized equipment. OboeTester is part of that effort. It can be run manually or from an Intent as part of an automated regression test. OboeTester provides lots of manual options, which is handy for debugging. But we need more automated tests for speaker paths, signal integrity, etc.
I agree that would be helpful. We have gotten many useful reports from app developers. That is one reason OboeTester is open source. But app developers can only test phones that have already shipped. We also need to provide more tests to manufacturers so that they can catch bugs before they ship.
I will investigate that possibility.
Can you elaborate on that? |
It is a subject of exploration regarding what android test team can do for testing audio. I think the possibilities are many once we start thinking in this line. The goal is to improve testability of audio on android. I thought the following mainly for Instrumentation tests:
|
Quick update: @philburk is investigating audio testing at scale |
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. 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(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):
The text was updated successfully, but these errors were encountered: