Currently we have UMA for highest buffer level.

https://uma.googleplex.com/p/chrome/histograms/?endDate=latest&dayCount=7&histograms=Cras.HighestOutputHardwareLevel&fixupData=true&showMax=true&filters=platform%2Ceq%2CC%2Call_version%2Cregex%2C71.0.*%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

https://uma.googleplex.com/p/chrome/timeline_v2/?sid=0b2038f6f2dbac769a0ba3d195d7f797

But this value does not really mean the delay of the stream.

1. It only considers delay caused by samples in the device buffer.
2. It should also take samples in the stream shared memory in to calculation.
3. By just looking at this value, it is hard to tell whether it is abnormally high delay or not, because it does not take stream block size into consideration.

We should improve this UMA value so it can be more meaningful to track regression.

An idea is to measure latency (we already have such API provided to client) and divide it by stream block size, and log the highest ratio to UMA when the stream is removed.
Normally this value should fall around 2 because CRAS 's scheduling maintain device buffer level around 1~2 minimum callback level, and minimum callback level is determined by stream block size.

If we see the increase in this value at some percentile like 50, 95, then there must be an regression.