Closed Bug 1566369 Opened 4 months ago Closed 4 months ago

Lower the audio thread pool thread count to 1 on Linux

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: padenot, Assigned: padenot)

Details

Attachments

(1 file)

This seem to work well: https://treeherder.mozilla.org/#/jobs?repo=try&revision=814cd62c22892ce6b194cdce01e1f12e38596d54

I've been running with this configuration for some time now, I haven't seen any problems.

This will help lowering the number of RT threads to 2 per content process, and help not reach the limit.

Assignee: nobody → padenot
Priority: -- → P2

I'm concerned this will lead to performance issues as we're now going to serialize every cubeb_stream callback on a single thread. It's simple to revert, though, so we can try it.

I'd prefer to retain the ability to use a multi-thread pool here, so if any upstream code starts depending on being called from a single stable thread that will cause problems for planned improvements in AudioIPC.

Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3b2470f9ae71
Lower the audioipc thread pool thread count to 1 on Linux. r=kinetik
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

(In reply to Matthew Gregan [:kinetik] from comment #2)

I'm concerned this will lead to performance issues as we're now going to serialize every cubeb_stream callback on a single thread. It's simple to revert, though, so we can try it.

It should be fine. most of the time, those thread are not loaded very high, and the stream events are not exactly happening at the same time, since, down the line, there is a mixer that needs to mix everything and do its job, and it's not running on multiple threads. When/if we support multiple output device, maybe it might be different.

I'd prefer to retain the ability to use a multi-thread pool here, so if any upstream code starts depending on being called from a single stable thread that will cause problems for planned improvements in AudioIPC.

There is the hard requirement that an AudioContext that runs JS or WASM in an AudioWorklet` is always running it on the exact same thread, because SpiderMonkey relies on TLS. We had to come up with https://searchfox.org/mozilla-central/source/dom/media/GraphRunner.cpp#26 because this is not yet the case.

This is however just for a specific AudioContext. Ideally, there would be multiple system level streams in the parent, and multiple threads in each child, and there should be a 1:1 relationship. We could certainly put all the high-latency AudioStream playing to the default device together.

Flags: needinfo?(padenot)
Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/264c44667919
Lower the audioipc thread pool thread count to 1 on Linux. r=kinetik
Status: REOPENED → RESOLVED
Closed: 4 months ago4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
You need to log in before you can comment on or make changes to this bug.