I have no updates here, please help reassign.

Oskar - could you take care of it? (I can point you to the API to use)

Sure thing! Please point me in the right direction and I'll try and figure out what data is reasonable to capture.

I think we want, at least, the device's friendly name logged whenever we do calls to create / open / start / stop / close etc. It's not straightforward to just get those at the point of call, however. We have the raw "device id", but that could be just "default" and on Windows it's utterly unreadable regardless - it's just a UUID. I don't want to add calls to resolve these names at those points in the code, as that will just make more calls into the audio stack we're trying to debug, possibly causing new hangs.

It looks like it's possible to create arrays of crash keys, so I think we should try and log the pertinent information for the first N (say four? eight?) input and output devices - including their device id. This can be updated whenever we enumerate devices. We can then keep updating just one key with the active device id, and refer to the mapping we made beforehand to figure out which device it actually is.

It's either that, or I'll have to add a proper cache of this information and use that to set the oft-changing keys.

Do we always have a device enumeration? I guess there are cases where a site will just open the default stream to play something out, without enumerating devices - or will that cause something to update internally?

Oh right, that's tricky: we have AudioDeviceDescription(s) cached on the browser side, but we are not caching them in the service, so cannot look up by device id. We could probably cache device info on  GetOutputDeviceDescriptions() calls to the service, and look it up on stream creation calls.