The relevant code;

https://github.com/luci/luci-py/blob/master/appengine/swarming/swarming_bot/api/platforms/osx.py#L189

https://github.com/luci/luci-py/blob/master/appengine/swarming/swarming_bot/api/platforms/linux.py#L74

https://github.com/luci/luci-py/blob/master/appengine/swarming/swarming_bot/api/platforms/win.py#L192

They are called from:
https://github.com/luci/luci-py/blob/master/appengine/swarming/swarming_bot/api/os_utilities.py#L949

watk@: as you're one of the domain experts in audio, could you please look at the code above and extend it to detect the presence of the new audio devices? A lot of effort was expended to purchase and install them, so your help on the final stages of deployment would be greatly appreciated. Thanks.

Yep, sure. I'm working on a stable blocker right now, so I won't get to it immediately.

Looks like the code to get the devices is already there, though. And we just need to verify there's both a recording and playback device.

How does the bot selection work? Will it look for a string in the published audio devices?

Is anyone depending on the output for audio devices currently? I was planning on changing the mechanism for looking them up from lspci to reading /proc/asound/cards.

maruel@ or vadimsh@ should answer the question about how the bot selection will work. My experience has been that a Swarming dimension must be advertised, which can then be used to select a subset of the bots on which to run. Not sure if one can select based on the Swarming state.

I don't think anyone is currently relying on the format of the audio part of the Swarming state.

There's a chunk of code that runs on a bot, examines its state, and returns dimension advertised by the bot: https://chrome-internal.googlesource.com/infra/infra_internal/+/master/services/swarming/bot_config_public.py#793

There it calls 'get_dimensions_all_devices_android' (https://github.com/luci/luci-py/blob/master/appengine/swarming/swarming_bot/api/os_utilities.py#L744) which for bots without phones attached is identical to 'get_dimensions' (https://github.com/luci/luci-py/blob/master/appengine/swarming/swarming_bot/api/os_utilities.py#L869).

There you'll see it exposes stuff like 'cpu', 'gpu', 'os', etc. Each one is an array of values supported by the bot.

One Swarming task is created, it has a set of dimensions it needs (e.g. such-and-such CPU and GPU). Swarming server assigns the task to particular bot.

'state' is not used for task assignments at all. It's just FYI information to see what's going on on the bot.

'audio' is not in dimensions now, so there's no way to schedule tasks based on audio card presence. And 'audio' in the state most probably is not being used by anything currently.

Gotcha, thanks for the details!

I'm thinking we expose two new dimensions: audio_inputs and audio_outputs which are either a count of the number of devices, or a yes/no.

Sound good? I don't think we need to expose the actual device ids since we don't care yet.

There's a constraint: total number of all possible subsets of dimensions returned by a bot should be smaller than some magical number (https://github.com/luci/luci-py/blob/master/appengine/swarming/server/task_to_run.py#L42).

So it's better to collapse multiple keys into single one, if possible, e.g. use 'audio' dimension with possible set of values ['in-out', 'in', 'out', 'none'] or something like that.

(it would increase total number of combinations only x2: either 'audio' is set or not. If using two keys, it'd be x4. I hope my explanation makes sense... Relevant code https://github.com/luci/luci-py/blob/master/appengine/swarming/server/task_to_run.py#L150).

Gotcha, then I'll probably start with: ['input-output', 'none'] since we have no current need for input only or output only.

phoglund@/olka@: do you have bandwidth to take on this task? I'm not able to get to it for a while.

I've never worked on test infrastructure and can't help with that in near future unfortunately.

Since nobody from the media team signed up for this task we're not going to pursue running audio tests on physical hardware at scale. If anyone wants to pick up this task in the future I'll be happy to work with them.