1553653 - Massive jank under CubebUtils::MaxNumberOfChannels when refreshing talky.io during a meeting.

Status: NEW

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

Description

[Emilio Cobos Álvarez (:emilio)]

See https://profiler.firefox.com/public/343d338417c322e67617a0d151c27e835582f8e8/calltree/?globalTrackOrder=0-1-2-3&localTrackOrderByPid=9494-1-0~&published&thread=3&v=3

May be a bug in my setup I guess? It's a pretty standard fedora installation, so I'd hope not.

I've been able to reproduce this a fair amount of times.

Comment 1

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Chun Min, does this make sense to you? Looks like we're waiting while trying to get the max number of channels, but I don't understand why, or quite how the CAPI interacts here.

Comment 2

[Matthew Gregan [:kinetik]]

cubeb_get_max_channel_count is potentially expensive depending on the implementation. In the PulseAudio backend, it's simply returning a field we queried earlier so it's quite cheap. In the WASAPI backend, we initialize an IAudioClient to query the result, which could be expensive. With audio IPC involved, we're also waiting on the response from the parent process so there's exposure to delay from context switching/scheduling on top of the raw cost of the query. This problem goes away by solving bug 1430704 (moving libcubeb calls off of the main thread), but there are potentially smaller solutions available at that level if necessary - we could cache the result in the libcubeb backend and/or the remoting code.

Before doing that, we need to work out if talky.io is causing this query to happen an unusually high number of times, or if the base cost of the query is too high. I'm not super familiar with the profiler UI - is it possible to see the call count, or are we stuck with cumulative times? I'm hoping this isn't a single call taking 23s!

Comment 3

[Emilio Cobos Álvarez (:emilio)]

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

Before doing that, we need to work out if talky.io is causing this query to happen an unusually high number of times, or if the base cost of the query is too high. I'm not super familiar with the profiler UI - is it possible to see the call count, or are we stuck with cumulative times? I'm hoping this isn't a single call taking 23s!

It's a sampling profiler, so I don't think there's call count information, but maybe Markus knows some tricks?

Comment 4

[C.M.Chang[:chunmin] | PTO]

I never use Fedora, but its default backend should be PulseAudio. In PulseAudio, the cubeb_get_max_channel_count should be quick since its data is cached after the cubeb context is created. However, after moving the Cubeb system calls to Gecko(parent) process, we need to wait the response of the IPC call on content(child) process to get the results. I think the time consumption here is the waiting time for IPC. I guess all the cubeb API calls on content process suffer the same problem before we have a way to solve bug 1430704.

Comment 5

[Paul Adenot (:padenot)]

There are weird interactions when multiple things happen at once in audioipc, such as getting the max channel count and initializing/closing a new stream, but I don't really understand why. I think the best way to diagnose this would be with some tracing like we do in Tracing.h, or of course an lttng trace but that's a bit (read: a lot) more involved maybe.

Comment 6

[Alex Chronopoulos [:achronop]]

I will remove the NI to Markus since he hasn't answered so far and it is not a question about the problem itself. I will also lower the priority since it something that never happens on my fedora and I use it all the time. Finally, I take the initiative to assign to Mathew since it looks like an AudioIPC issue. Feel free to change all these if you don't agree.