Consistent 1 Second or Greater Microphone Latency Issue

User Support General
1

Problem: consistent latency between microphone and playback - around 1s. The quality’s also not ideal for calls, with some reports of it being crackly but audible that I wasn’t picking up in local playback. There’s no latency or quality issue with incoming audio, and video/screensharing are also okay. I’ve had instances where the mic latency gets into the 5s+ range, but can’t reproduce that.

Consequence: I’m using a separate system for all audio/videoconferencing. Might not be a bad idea but it’s unexpected and not my preference.

First attempted 9-12 months ago, and I did some digging 6 months ago. I was hoping for more focus time or inspiration since then, but haven’t found either.

Same results:

  • using Google Meet, Zoom, and a clean jitsi server install on my local network
  • using the built-in microphone and a separate one plugged into the audio i/o port. I don’t want to get extra hardware in right now just for this testing.
  • giving more resources to the audio+client vms
  • changing the virtualization/memory balancing/PCI configurations
  • using multiple WLANs (no ethernet option)

Same hardware with a live boot Ubuntu did not have the issue. iirc this was using pulseaudio and not pipewire. lsmod looked very similar, but I don’t do much with drivers and could have missed something.

I’m trying to avoid deep-diving into pipewire. I’ve followed some of the basic pipewire latency guidance like setting environment variables, verified that they’re set correctly, and can’t see a difference.

I tried to test at different layers with arecord -- | aplay and similar things with pacat/pactl/pw-cat. Some of these seemed to reproduce a similar lag even when configured to remove built-in latency, but it turned out they also reproduced it on the working Ubuntu system where audio calls were fine. So I didn’t find a cheaper way to test than setting up a call between two systems.

I haven’t yet tried testing with calls between different local VMs - looks like this should be okay to set up so it’s my next step.

I also wanted to test dummy input instead of the mic, but haven’t worked out how to do that yet.

I haven’t tested with Qubes on a separate system. I’m assuming it is somehow hardware-specific at this stage, mainly because I can’t find similar reports and my system’s fairly clean.

I’m on Qubes 4.2.3 with an audiovm. No other problems with it.

I’ve checked the forum and issue tracker and not spotted anything very similar or recent. I’d like to know if anyone has had a similar problem, and if there’s anything obvious that people who know their audio would check, or anything else likely to narrow down the cause.

1 Like
2

I do not use an AudioVM and my video conferencing setup does not have any latency, so maybe you could try temporarily disabling the AudioVM to see if that changes your situation. You can also test against my own Jitsi Meet instance for another data point:

If neither of these help, provide details of your hardware configuration.

1 Like
3

I got a similar issue on a computer with a weak CPU. what are your computer’s specifications? How is the microphone connected?

2 Likes
4

Since you mentioned workarounds/alternatives, another one might be considering attaching a USB headset to sys-audio and trying that

I don’t currently use sys-audio, so I can’t say for sure it will resolve your issue. But in most countries, you can purchase a headset from somewhere like Amazon and return it at no cost if it doesn’t help

I know this isn’t a suitable solution for everyone, so I don’t recommend you give up on diagnosis and resolution yet, though, unless you want a quick fix and have $20-$100 to spend

One thing you can check is kernel level/driver errors in your sys-audio

Reproduce the issue, then check the output in sys-audio, looking for errors about PCI devices, resource exhaustion or driver errors:

$ sudo dmesg | tail -n 200
$ sudo journalctl -k

Alternately, you can monitor the logs in real-time in sys-audio while reproducing. I haven’t used journalctl in this way, but I understand it as similar to tail -f. You would run this in sys-audio first and leave it running:

$ sudo journalctl -f

This has been helpful for me in the past for other devices in cases where swiotlb was set too conservatively. I don’t think it’s necessarily the problem here, but it’s quick to check and could reveal other causes

2 Likes
5

I’ve tested this less than I’d like because I’m not sure how clean disabling the audiovm is, so I do I full restart afterwards, but yes I want to look at this again.

It’s a recent laptop with an Intel i5. It does most things much faster than my other systems but can run hotter for things like video. I’ve tested with different CPU turbo and power save settings - no difference in the mic latency issue.

I should also clarify, I do get the mic issue with audio-only calls.

Internally, don’t know, will check.

I was going to test this but didn’t have anything to hand. Loads of other peripheral junk, but no USB headsets. I’ll sort something.

I’m checking dmesg and the journal pretty routinely and there’s nothing in my notes, but I keep an eye on it.
When testing with some of the alsa utilities I could see xrun messages on stderr (I guess that’s expected if I was forcing latency to 0), but haven’t found them in any logs during calls.

I haven’t gone near iommu configuration before but can take a look.

Not sure what I do/don’t want to share right now. I may come back to this after trying out specific suggestions, or let me know if there’s something particular you want to know.

Thanks for all suggestions. I’ll go for another batch of testing in the next couple of days.

1 Like