The URL posted is for display tests only.

Here is the URL for audio tests: https://wmatrix.googleplex.com/unfiltered?suites=chameleon_audio_perbuild,chameleon_hdmi_perbuild&tests=audio_AudioBasicExternalMicrophone,audio_AudioBasicHeadphone&platforms=veyron_jerry,peach_pi,link,squawks&days_back=14

The 'scp' failures reason are the ones motivated us to start this effort.

Thanks Kalin!
These four boards looks stable enough to me.
We definitely don't want to block cq too often.
Should we dedicate some of these devices to bvt-cq ?

Mmm, ok, lets 
Per go/chameleons-in-lab view we can do this with jerry and link. I misread there are four pi DUTs with chameleon.

veyron_jerry - chromeos2-row1-rack4-host1
veyron_jerry - chromeos2-row1-rack4-host2
veyron_jerry - chromeos2-row1-rack4-host3
veyron_jerry - chromeos2-row1-rack4-host4
link - chromeos2-row4-rack3-host8
link - chromeos2-row4-rack3-host9
link - chromeos2-row4-rack2-host12
link - chromeos2-row4-rack2-host7

If we insist on squawks we can file a request for two more boards to be equipped with chameleon(respectively with audio board too)

I'll file requests for 
1) adding four audio board to each of jerry and link 
2) adding two more chameleon boards to squawks DUTs and four audio boards.

Now, is there a chance that having audio jack plugged could break anything on bvt-cq? We should probably run the suite against few boards with the same setup in cassandra lab.

+dshi for any suggestions about adding tests to bvt.
Dan, what would be the guideline we should follow?

+infra deputy

The basic rules for tests in cq suite are:
1. The test needs to be constantly passing on canary builds for the last two weeks.
2. The test run time should be relatively short, around 2min tops.

Rule 1.The test needs to be constantly passing on canary builds for the last two weeks.
- How do we arrange this? What test suite to assign to?


Rule 2. The test run time should be relatively short, around 2min tops.

 - display_Resolution.extended - Duration [s]	153 - GOOD
 - display_HotPlugAtSuspend.extended - Duration [s]	218 - GOD
 - display_HotPlugAtBoot.extended - Duration [s]	385 - this should be fixed by having new (control.bvt) test that goes through a single item in PLUG_CONFIGS 

 - audio_AudioBasicExternalMicrophone - Duration [s]	205 - GOOD
 - audio_AudioBasicHeadphone - Duration [s]	226 - GOOD

suite bvt-perbuild should be a good candidate. The suite runs on canary builds.

3-4 min is a bit long, but not too bad, I think it should be OK.

Ohh, right. I folded the running time when looking at duration. I'll follow up on making faster test runs for  most of the tests.

We only want to run some of the stable tests on several boards, e.g. veyron_jerry, peach_pi, link, and squawks. Is it doable?

About the speed, we can customize the tests (using another control.bvt) to run only a subset of test items.

It will be easy for a single board, you can add board:xxx to the DEPENDENCIES attribute. Are these boards share some common label? I think it will be kind of messy. You might have to create individual test control file for each board.

OK, then to keep it simple we can start with a single board - Jerry.

Tasks to start with
- Add audio board to the veyron_jerry DUTs - chromeos2-row1-rack4-host1...host4
- modify test to accomodate faster execution.
- create separate tests with control files pointing to 
DEPENDECIES = 'board:veyron_jerry audio_board' and 
SUITE = 'bvt-perbuild'


If we observe failures that fail only on specific board family, we should add audio boards to such board DUTs.

https://buganizer.corp.google.com/u/0/issues/27477762 is tracking the deployment task.

Four audio boards are added to the veyron_jerry DUTs chromeos2-row1-rack4-host1...host4

Next steps

1) Make tests faster 
- display_Resolution.extended
- audio_AudioBasicHeadphone
- audio_AudioBasicExternalMicrophone

2) Start running the tests for bvt-perbuild

3) Add few more tests
- display_HotPlugAtSuspend.mirrored
- audio_AudioBasicUSBPlayback

4) Cover more devices