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?
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