Awful conference performance and unable to troubleshoot it

Ask Fedora
, ,
1

Problem

Conferencing with Google Meet and alternative on Fedora 42 has awful performance. Even with turned off outgoing video, the incoming A/V streams are stuttering, especially when switching to other tabs. People report that outgoing wired microphone sound is bubbling at start, and there is noticeable lag, which disrupts communication. The bluetooth phones are used as a sound target, and the headset codec is set to AAC.

The actual problem is that there is no way to troubleshoot the performance of the whole pipeline. Which codec depletes resources (100% CPU Core), which is not given the necessary priority, where the mem/swap is occurring.

With the performance tool and troubleshooting manual it is possible to at least distill this to separate issues.

Cause

Not yet known.

dmesg shows this. No idea what it means.

[ 8362.389283] Bluetooth: hci0: corrupted SCO packet
[ 8362.389285] Bluetooth: hci0: corrupted SCO packet
[ 8454.212645] perf: interrupt took too long (3988 > 3987), lowering kernel.perf_event_max_sample_rate to 50000
[ 8740.818540] perf: interrupt took too long (5022 > 4985), lowering kernel.perf_event_max_sample_rate to 39000
[ 8961.649346] Bluetooth: hci0: corrupted SCO packet
[ 8961.649352] Bluetooth: hci0: corrupted SCO packet

Related Issues

Bugzilla report: #NNNN

Workarounds

None yet.

3

In general, when using a Bluetooth headset with Google Meet or other WebRTC-based apps, the system needs to switch the Bluetooth profile from A2DP (high-quality audio, no mic) to HSP/HFP (lower-quality audio, includes mic support) to allow microphone input.

This profile switching can sometimes lead to:

  • Audio stuttering or poor sound quality (especially in the HSP/HFP profile)
  • Unstable AV streaming during video calls
  • Latency or buffering issues, especially on lower-bandwidth Bluetooth connections

These issues are not unique to Fedora 42, but could relate to how the system handles Bluetooth profile changes, the PipeWire audio stack, or even wireless interference or browser behavior under WebRTC load.

Using a USB microphone while keeping the headset in A2DP mode is one common workaround to maintain better audio output during calls from my experience.

Normally, AAC is used with the A2DP profile, which isn’t supposed to support microphone input—so if a call is active, the profile should have switched to HSP/HFP instead. This raises some questions about whether the profile switching is working correctly.

1 Like