Re: [webrtc-stats] Stat for audio playout delay

Picking up the discussion deferred here from #146.

_What did the non-standard accelerate and pre-emptive expand rates try
 to quantify?_ Possibly audible stretching and compression (in the 
time domain). The underlying reason for the signal operation is 
probably less interesting, but usual cases are A/V syncing and meeting
 target buffer level (i.e., when high or low water marks are passed).

We need separate metrics for increase and decrease, since a net zero 
doesn't mean that no potentially audible operations were performed.

This does _not_ capture any delay changes resulting from the 
packet-loss concealment operation (see #152).

-- 
GitHub Notification of comment by hlundin
Please view or discuss this issue at 
https://github.com/w3c/webrtc-stats/issues/151#issuecomment-280629504 
using your GitHub account