On 17 May 2012 00:12, Harsh Prateek Bora harsh.bora@linaro.org wrote:
On 17 May 2012 01:35, Paul Larson paul.larson@linaro.org wrote:
On Wed, May 16, 2012 at 1:43 AM, Harsh Prateek Bora < harsh.bora@linaro.org> wrote:
On 16 May 2012 09:38, Paul Larson paul.larson@linaro.org wrote:
On Tue, May 15, 2012 at 4:24 PM, Tom Gall tom.gall@linaro.org wrote:
HI Paul,
On Tue, May 15, 2012 at 4:14 PM, Paul Larson paul.larson@linaro.org wrote:
Cool, does this replace the existing e2daudiotest I guess?
Please consider it as complementary.
Ah, I see after looking at it a bit more. This one isn't completely
automated and requires someone to listen to the sound :)
Yes, Its the initial phase and therefore will evolve with time as required. We may want to plug-in e2eaudiotest and others if already available. As of now, it frees the user from finding out the card, device info for each audio playback/recording device on supported hardware and can help in identify issues where audio is almost ok, but not truly perfect (like choppy audio). Un-attended tests may treat imperfect audio as bad as no audio. I hope I am able to convey what I intend to do so.
Ah, so if e2eaudiotest is plugged into it, it could act as a sort of
front-end for running it and making sure that the right audio device is set up for that particular board? So in this way, it could allow for automated tests, not just interactive ones?
The tests in question are really for different audiences. The e2eaudiotest tool was designed to be in a fully automated environment as a build sniff test that does not require a human to see if the entire audio stack on a particular board/build works "good enough" using a default path.
The test script is to provide an interactive umbrella tool for the developer to exhaustively test the stack before upstreaming. This can include the former tool, but doesn't need to.
Yes, we can add more as well !
regards, Harsh
Thanks, Paul Larson