Open Bug 1480348 Opened 6 years ago Updated 2 years ago

Cubeb for pulseaudio hangs with lots of "pa_write() failed while trying to wake up the mainloop: Resource temporarily unavailable" logged

Categories

(Core :: Audio/Video: cubeb, defect, P2)

Product:
Core
Component:
Audio/Video: cubeb
Version:
60 Branch
Type:
defect

Tracking

()

People

(Reporter: pehrsons, Unassigned)

References

(Blocks 2 open bugs)

Details

We see this with both loopback and real devices, on both opt and debug, both locally and on try, both e10s and non-e10s.
It's worse with audioipc than with cubeb-rs but can still be hit.
Seems to be triggered by opening multiple MediaStreamGraphs for the same input device (gUM audio requests from different documents).
Is preceded by what seems like a gUM hang, but with enough patience gUM resolves and the log quickly fills up with "pa_write() failed while trying to wake up the mainloop: Resource temporarily unavailable".
Debug builds on try seem to time out before we see the log message but I'd guess they are just too slow so we time out first.

See [1] for an example. Sadly it doesn't include js logs. The debug build failures do, but they don't have the logged message.

STR:
- Import all of padenot's patches from bug 1404977.
- Import Bryce's iframe test, rev 2, from the same bug: https://reviewboard.mozilla.org/r/260476/diff/2
- ./mach test dom/media/tests/mochitest/test_getUserMedia_multipleIframesDifferentConstraints.html --use-test-media-devices


[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=85c80ddceaef6e38f9dcddebc3a516d107ac6dd3&selectedJob=191353246
I'm not making this a P1 as I don't think it's a new issue. It's just bug 1404977 that's enables the use case needed to hit this. Without it you should be able to achieve the same symptoms with enough e10s child processes and making the gUM requests in multiple of those.

High P2 instead.
Rank: 10
Priority: -- → P2
I also got an instance of this without bug 1404977 applied, [1]. That indeed proves that this is a latent issue. It would however be good to have a remedy for it before letting bug 1404977 loose while we are waiting for any kind of proper fix.

An idea that has been surfaced before is to limit the number of concurrent MSGs using the same input device in the same child process (much like pre-1404977) artificially via a pref.

Most of the linux mochitest-media issues on bug 1411358 seem to be this issue.


[1] https://treeherder.mozilla.org/#/jobs?repo=try&author=pehrsons@gmail.com&selectedJob=191548915
Blocks: 1411358
An observation.

When testing many gUM requests in multiple iframes manually with bryce's codepen [1] it seems like the result of one of the slow gUM requests is a built-up pulseaudio buffer. I.e., after a slow request the input-to-output latency increases by roughly the wall-clock time the request took.


[1] https://codepen.io/SingingTree/pen/BxWePB
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.