Add audio owners for triaging.

jonathan@titanous.com: Does this happen on any other platforms, e.g. Win/Mac/Linux? Thanks!

+Marina could you try to repro it with AudioServiceAudioStreams feature enabled?

+Vasan, do you maybe have a ChromeOS setup with AudioServiceAudioStreams feature enabled? Can you please help us with this and try to repro this bug?

Hi all,

I could not reproduce the issue with and without the flag in Falco (68.0.3440.15). This issue could be device specific with Eve. 

In our lab we are waiting for Eve chromebook to be delivered. Hopefully in couple of days we will get a device. 

P.S: Tried both youtube and Spotify. Meanwhile will try if reproducible in other chromebooks. 

Thanks Vasan.

jonathan@ could you please:
1) Close all the tabs except the one to play media from.
2) Start a playback, wait for a minute.
3) Start trace recording with media and audio categories only. [https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs]
4) Right after that press pause.
5) As soon as audio is paused stop trace recording.

And upload the trace recording to this bug.
Thank you!

It was a bit harder than I expected to reproduce, but after leaving Spotify playing for around 10 minutes I managed to grab a trace.

Deleted: trace_spotify_pause_lag.json.gz 851 KB

trace_spotify_pause_lag.json.gz 851 KB Download

Thanks jonathan@. Unfortunately, There are no controls events in the trace for some reason.
Have you started tracing before hitting the pause? (please do so)
Were you recording traces "until full" or "continuously"? (please use "until full" mode)
Have you checked both "audio" and "media" categories?
Could you try to repro again?

---
For the record: basing on trace info, AudioServiceStreams experiment is enabled

+ some more media folks in case it's a pipeline problem.

The reported delay of AudioOutputDevice::FireRenderCallback is 6 seconds. Maybe the delay was somehow accumulated during playback and cras has 6 seconds of audio buffered up internally that it flushes?

+Kalin,

Hi Kalin, could test team try to reproduce this issue and grab audio_diagnostics logs when issue happens ? If we can get audio_diagnostics during that 6 seconds, that will be very helpful.

Thanks!

olka@:

> Have you started tracing before hitting the pause? (please do so)

Yes, for 1-2 seconds.

> Were you recording traces "until full" or "continuously"? (please use "until full" mode)

until full

> Have you checked both "audio" and "media" categories?

Yes.

> Could you try to repro again?

Sure is there anything I should do differently?

Here's another trace. Recording started a few seconds before pause, and stopped a few seconds after the audio stopped playing. Spotify had played for about six minutes across two songs before I paused.

Deleted: trace_spotify_pause_lag2.json.gz 1.0 MB

trace_spotify_pause_lag2.json.gz 1.0 MB Download

And another trace with about the same timings as the last one. I also attached the audio_diagnostics log collected a little bit after the trace ended, I'm not sure if it covers the period of time in question though as I'm not sure how the timestamps/rolling log buffer works. Let me know if there's a better way to grab the log than opening chrome://system right after the trace ends.

Deleted: trace_spotify_pause_lag3.json.gz 933 KB

trace_spotify_pause_lag3.json.gz 933 KB Download

Deleted: audio_diagnostics_spotify_pause_lag3.txt 557 KB

audio_diagnostics_spotify_pause_lag3.txt 557 KB View Download

> The reported delay of AudioOutputDevice::FireRenderCallback is 6 seconds.

Very suspicious (and matches reporter's keeps playing). If we can get a repro this is the place to start IMO.

Seems like OS level issue if that's the delay value. OS is accumulating audio faster than it can play it out.

Is https://buganizer.corp.google.com/issues/110719839#comment29 related?

#16: those stats are recovering in M69: https://uma.googleplex.com/p/chrome/timeline_v2/?sid=0156b2d57301b0726d41b58522533800

It would be good to know the effective CL in M69 and merge it to M68. WebRTC and Chromebox for Meetings (CfM) may also be suffering from it, see
https://buganizer.corp.google.com/issues/110719839
and
https://b.corp.google.com/issues/111543423
respectively.

We suspect this issue is the root cause of b/112451744 which is currently P1 and is holding up 68 stable push for Chrome OS so marking this bug accordingly.

FYI, my team was able to repro this and we have submitted a feedback (googler krystineo@) on Aug 17 - the feedback should include system logs etc. HTH. 

This is believed to be fixed by https://chromium-review.googlesource.com/c/chromiumos/third_party/adhd/+/1183660 which is now merged to 68, if this is still seen please feel free to reopen.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-68; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-68 label, otherwise remove Merge-TBD label. Thanks.

Closing as verified.